Planet ccppbrasil.org

- FISL10

2009-07-02T02:49:28+00:00

Depois de tantos anos tentando me programar para ir ao FISL e sempre surgindo imprevistos, consegui graças a minha namorada que deu a idéia e incentivou bastante para que fossemos ao FISL10 e consequentemente conhecer a cidade de Porto Alegre! Compramos passagens e reservamos hotel desde de Janeiro, sendo um dos fatores que fez nos economizarmos um trocado! Abaixo segue um resumo de como foi está experiência!!

.:: FISL 10 ::.

<aviso>Este POST com certeza foi o mais pesado que escrevi até o dia de hoje! talvez demore para carregar… </aviso>

# Day0: Depois de sair de Recife ás 03:15am fazendo escala em são paulo, chegando em POA ás 09:30am!

Day0: Logo no aeroporto em Recife encontrei o parceiro "Moisés beniGNU", perceba na foto acima que ele estava meditando na cadeira ao lado durante todo trajeto...

Day0: Assim que chegamos na cidade fomos direto para a PUC, antes no caminho uma parada para foto!

Day0: Direto para a PUC pegar as credenciais e escolher um estande para o GNOME-BR.

Day0: Marcando o estande que consegui no melhor ponto possível!

Day1: (24/06) Acordamos cedo no primeiro dia de evento, e fomos direto para a PUC! Muita adrenalina e animação para rever e trocar idéia com os amigos e ainda fui conferir a palestra do Ricardo Salveti sobre “Desenvolvimento embarcado com Open Embedded e Mamona”.

Day1: Eu e Wendell logo cedo no estande... qualquer semelhança da foto do Wendell com o personagem "Bender" do seriado "Futurama" e pura Coincidência!

Day1: Foto clichê com Jon "MadDog" Hall...

Day1: Grande figura, Lucas Brasilino!

Day1: Os amigos de Recife marcando presença no FISL (Pedro + Wesley "Tarado do VOIP" + Dailson "Fofão" + Moisés beniGNU + Eu), Jantar com um Bom vinho para fechar a noite!

Day1: Fechando a noite em um jantar com os amigos e um bom vinho!

Day2: (25/06) Começamos o dia com agitação logo cedo!

Day2: Na ida para o FISL nos deparamos com uma manifestação na frente da prefeitura de POA, e então fomos lá da uma força ao pessoal...

Day2: Comprando alguns vinhos para esquentar... já que o frio estava demais!!

Day2: Eu e minha gata na frente da PUC diante banner gigante do evento...

Day3: (26/06) Um dos dias mais corridos, muito Hacking relacionado ao GNOME, inclusive apresentação falando sobre a evolução e participação relacionadas ao GNOME! Foi apresentada por Jonh Wendell, Gustavo Noronha (kov) e o Júlio Cesar! Foi bem divertida inclusive em relação as discussões que rolaram durante apresentação!

Day3: Eu e Wendell discutindo sobre melhor forma para implementação do esquema de plugins para o VINAGRE... Breve um post sobre o assunto! Como diria o Stallman, Happy Hacking"

Day3: Que maravilha, esquentando a alma diante a lareira lá na churrascaria CTG...

Day3: Eu e minha Gatona... Um choppzinho para refrescar o calor de +6 graus! Ninguém e de ferro...

Day4: (27/06) Muito frio como sempre, muito discussão, e fui conferir duas palestras. A primeira foi do Francisco Alecrim que falou sobre desenvolvimento para as placas Beagle Board, sem sombra de dúvidas a palestra foi excelente, Mais informações no blog dele e a segunda foi do Gustavo Noronha (kov) falando sobre “WebKitGTK+ – O Que é e como usar”, foi com certeza uma das palestras mais técnicas que teve no FISL!

Day4: Eu e o Vinícius diante uma relíquia... um belíssimo K82-C contendo 2k de espaço!!

Day4: Vinícius + Eu + Krix + Wendell + Tiago (T-Rex) + Luciana + Pequeno Gustavo

Day4: Eita, eu na mídia... haha! no quarto dia do evento a "Vanessa Nunes" passou lá e me chamou para participar de uma matéria que ela estava escrevendo sobre a cara dos laptops de alguns participantes! Clique na foto para ver a matéria!

Day4: Último dia de FISL... nós na saída do prédio diante o banner principal de entrada!

Day5: (28/06) Este foi o dia que eu e Krix tiramos para passear e conhecer um pouco mais da cidade, Com certeza e a melhor forma de conhecer o Guaíba e o Delta do Jacuí são os passeios com os barcos Cisne Branco, com saída no Portão Central do Cais do Porto! Vale realmente a pena!

Day5: Eu e minha gata fechando com chave de ouro o passeio em POA com um jantarzinho acompanhado de uma boa caneca de vinho!!

Day5: Eu e ela!

Day5: Foto tipo cartão postal!

Considerações sobre o FISL!

O FISL e um evento que você encontra de tudo! Hackers por todos os lados, GNOMER’s, Ubuntusers, Slackwazeros, Debianzeros, PHPZeros, CZeros entre a mais vasta especie que você possa imaginar!
A estrutura da PUC sem sombra de dúvidas e muito boa, porém para o nível que o FISL é deixou a desejar em muitas coisas dentre elas a má sinalização no campus, péssima qualidade da internet e sinal wi-fi!
Grande oportunidade para rever e conhecer os amigos que você só conhece por Email/IRC além de reforçar em MUITO o Networking!
Conforme o Fábio citou neste post, e incrível o quanto o Ubuntu impera nos Desktops!
Sobre a visita de Lula no evento? Eu prefiro não comentar NADA sobre o assunto!
Mais fotos que tiramos podem ser visto no Flickr de Krix aqui!
Richard Stallman dançando breaking, tem noção da cena? veja o video aqui e aqui também!
No vôo de volta na escala entre São Paulo e Recife veio no mesmo vôo eu, Krix e Ursula que podemos ter a companhia de uma “Crente” orando e agonizando durante quase todo o trajeto… ou seja, ela veio “enchendo o saco”!
Foi muito ruim ter que ficar o dia inteiro dentro de avião para chegar ao Rio de Janeiro, pois fiz os trajetos “POA” -> “São Paulo” -> “Recife” -> “Rio de Janeiro”.

Considerações sobre a Cidade!

Porto alegre e uma das cidades mais belas que conheci aqui no Brasil, sem sombra de dúvidas possui muitos outros cartões postais na cidade e no estado do Rio Grande do Sul!
A Cidade e praticamente um “Frigorifico”, meu grande companheiro Dailson que estava hospedado no mesmo hotel gritou várias vezes durante os dias “Por favor, alguém diminuir o nível deste ar-condicionado central”, haha!
O Custo de vida lá em relação a alimentação e SUPER barato em comparação a outros cantos como por exemplo Rio de Janeiro, Recife e São Paulo!
Com certeza uma das melhores gastronomias do Brasil, fiquei impressionado com a qualidade das comidas que comi durante os dias de evento! Lá o povo sabe realmente temperar uma comida de verdade!
Pretende visitar a cidade em época de frio? PREPARE-SE! VÁ BEM AGASALHADO!

Nos vemos no FISL11, ate lá!

http://franciscoalecrim.com/blog/2009/07/02/fisl10-material-fotos-comentarios-e-agradecimentos/CF

0xc0de

2009-06-27T18:30:21+00:00

Sugestão de implementação do construtor de cópia e operador de atribuição em C++:

Crie um construtor de cópia com passagem de parâmetro por referência para uma constante.
Crie um operador de atribuição com passagem de parâmetro por valor e retorno por referência.
Crie uma função membro de swap. Idealmente, que não lance exceções.
Dentro do operador de atribuição, faça a troca (swap) entre o argumento construído por cópia e o objeto apontado por this.

Essa é uma solução elegante e sem redundâncias (considerando que todos os swaps estejam corretamente implementados). Além disso, não depende da verificação de auto-atribuição no operator=. Para detalhes relacionados a exception-safety, clique aqui.


class person
{
public:
    person(std::string name);
    person(person const& other); //Construtor cópia.
    person & operator=(person other); //Operador atribuição.

    void swap(person & other) throw();

private:
    std::string name_;
    unsigned short age_;
    /* ... */
};

person::person(std::string name):
  name_(name), age_(0) /* ... */
{}

person::person(person const& other):
  name_(other.name_), age_(other.age_) /* ... */
{}

person & person::operator=(person other)
{
    other.swap(*this); //Troca com a cópia recebida.
    return *this;
}

void person::swap(person & other) throw()
{
    name_.swap(other.name_);
    std::swap(age_, other.age_);
    /* ... */
}

Lembre que nem sempre é necessário declarar/definir esses membros para todas as classes. O código acima visa apenas ilustrar uma forma de implementação.

Leandro T. C. Melo

bcsanches

2009-06-15T13:54:22+00:00

Este semana rolou um email bem legal na lista de emails cppbrasil, o email continha o link para um mapa do C++ no estilo usado em mapas antigos:

O post original do mapa pode ser encontrado clicando-se aqui, inclusive contem opções de tamanho.

- Resumo: Casa nova, Brinquedo Novo, Tatoo, …

2009-06-14T20:49:36+00:00

Mais de um més sem nenhum POST novo aqui no meu blog. Mais isto e justificável, pois muita coisa aconteceu e vem acontecendo nesses dois últimos meses! Irei escrever um único post envolvendo tais novidades!!

Casa Nova

Devido a alguns imprevistos e afins surgiu a necessidade de me mudar e estou morando e trabalhando atualmente na famosa “Cidade Maravilhosa”, isto mesmo! Estou desde o último dia 09 de Maio morando no Rio de Janeiro!!

Copacabana, ao fundo o Pão de Açúcar!

Entardecer em Copacabana...

Porém não vim para cá como turista e sim para trabalhar, que por sinal trabalho não tem sido outra coisa que tenho me dedicado tanto! O Desafio de trabalhar com novas tecnologias envolvendo TV Digital & Linux embarcado, foi um dos maiores motivos que me fez aceitar o desafio de mudar de cidade, deixar para trás familiares, amigos, minha filhota e minha girl linda!!

Brinquedo Novo, Guitarra Fender Squier

Quando mais novo havia tido interesse para aprender a tocar violão e aprendi alguma coisa, só que depois de muito tempo com a vontade retraída em aprender a tocar Guitarra resolvi a algum tempo investir um pouco do tempo livre (tempo livre? O_o)! Consequentemente um amigo comprou uma guitarra e amplificador novo e conversando ele ficou sabendo sobre esta minha vontade desde de guri em aprender a tocar e me vendeu por um valor MUITO legal! Valeu Gustavo!

No pacote veio: Guitarra Fender Squier + Alça + Palhetas + Mochila + Suporte + Amplificador Shelter (Tudo extremamente novo, a guitarra não tem nenhum arranhão e inclusive o Amplificador ainda veio na caixa original)

Tatoo : Finalizado Braço esquerdo!

Desde de novo que sempre tive atração por tatuagem, muitas pessoas recriminam e falam muito! Porém tenho apenas uma concepção que num vai ser um desenho que vai dizer algo sobre a dignidade da pessoa, pois em Brasília tem muita gente de terno-gravata roubando e sujando a imagem do país então sobre isto prefiro nem comentar! Enfim, está foi a última sprint da minha tatuagem do braço esquerdo, a próxima será o meu maior projeto sobre o assunto! Será o sonho de ter desenhado nas costas a arte da capa do álbum Powerslave do Iron Maiden, abaixo tem um exemplo da arte! Pretendo fazer em breve!

Maori estilizado feito pelo mestre "Andarilho"

Um dos principais motivos do meu real interesse pelo Iron Maiden começou primeiro pelas capas dos discos, segundo por influência de meu primo que juntamente com um amigo escutavam muitas bandas do genero entre elas era o Iron. E este com certeza e um dos melhores álbuns na minha opinião, foi o quinto álbum de estúdio da banda lançado em 3 de setembro de 1984, nesta época eu estava apenas com dois anos de idade! O álbum tem sua abertura com “Aces High”, uma canção sobre as lutas aéreas na Segunda Guerra Mundial. Logo depois tem “Two Minutes to Midnight”, composta por Adrian Smith com letras de Bruce, tratando da constante ameaça de uma guerra nuclear que pairava na época. Logo após, uma canção instrumental ao estilo egípcio do álbum, chamado “Losfer Words (Big’ Orra)”. Depois as canções “Flash of the Blade”, “The Duellists” e “Back in the Village”. Segue “Powerslave”, composta apenas por Bruce Dickinson e que trata de temas egípcios e como as pessoas podem ficar “escravas do poder”. Por fim, a “saga” “Rime of the Ancient Mariner”, uma longa canção de treze minutos sobre um homem amaldiçoado por uma sereia da morte. Foi escrita a partir do poema homônimo do poeta romântico inglês do século XVIII, Samuel Taylor Coleridge! Enfim, este será o tema de minha próxima tatoo que espero poder fazer em breve!

Este e um exemplo do próxima tema de minha nova Tatoo! Up the Irons! o/

Combination Tree

2009-06-10T20:49:51+00:00

This sample generates a set of combined numbers. These numbers are grouped inside a tree structure, which I called combination tree.

It was built with Visual C++ 2010, using C++0x features (TR1 and lambdas).

#include <array>
using std::array;
using std::get;

#include <memory>
using std::shared_ptr;

#include <algorithm>
using std::for_each;
using std::transform;

#include <string>
using std::string;

#include <list>
using std::list;

#include <iostream>
using std::cout;
using std::endl;

template<typename T, size_t N>

struct Leaf
{
typedef shared_ptr<Leaf<T, N>> LeafType;
typedef shared_ptr<array<LeafType, N>> LeavesType;

explicit Leaf(const T& value) : Value(value){}

LeavesType Leaves;

T Value;
};

template<typename T, size_t N>
struct CombinationTree
{
typedef typename Leaf<T, N>::LeavesType LeavesType;
typedef typename Leaf<T, N>::LeafType LeafType;

explicit CombinationTree() : Root_(make_Leaves()){}

void add( array<T, N>& value )
{
    if( get<0>(*Root_) ) assign_Leaves( Root_, value ); else assign_Values( Root_, value );
}

const LeavesType& get_Root() const { return Root_; }

private:
LeafType make_Leaf( const T& v ) const { return LeafType( new Leaf<T, N>(v) ); }
LeavesType make_Leaves() const { return LeavesType( new array<LeafType, N> ); }

void add_Leaf(LeafType& leaf, array<T, N>& value)
{
    auto& leaves = leaf->Leaves;
    if ( leaves.get() )
    {
      assign_Leaves( leaves, value );
      return;
    }
    leaves = LeavesType( new array<LeafType, N> );
    assign_Values( leaves, value );
}

void assign_Leaves(LeavesType& leaves, array<T, N>& value)
{
    for_each( leaves->begin(), leaves->end(), [this, &value](LeafType& l){ add_Leaf(l, value); } );
}

void assign_Values(LeavesType& leaves, array<T, N>& value) const
{
    transform( value.begin(), value.end(), leaves->begin(), [this](const T& v){ return make_Leaf(v); } );
}

private:
LeavesType Root_;
};

template<size_t N>
struct NaiveDumpCombination
{
const list<string> operator()( const CombinationTree<string, N>& tree )
{
    auto leaves = tree.get_Root();
    list<string> combinations;
    for_each
    (
      leaves->begin(), leaves->end(),
      [this, &combinations](shared_ptr<Leaf<string, N>> l){ GetCombinations( l, l->Value, combinations ); }
    );
    return combinations;
}

private:
void GetCombinations( const shared_ptr<Leaf<string, N>>& leaf, string s, list<string>& combinations )
{
    if( !leaf )
      return;

    auto& leaves = leaf->Leaves;

    if (!leaves)
    {
      combinations.push_back( s );
      return;
    }

    for_each
    (
      leaves->begin(), leaves->end(),
      [this, s, &combinations](shared_ptr<Leaf<string, N>> l)
      {
        GetCombinations( l, s + " " + l->Value, combinations );
      }
    );
}
};

int main()
{
//combinations with repetition
NaiveDumpCombination<5> dump;
CombinationTree<string, 5> tree;
array<string, 5> a = { "1", "2", "3", "4", "5" };
tree.add(a);
tree.add(a);
tree.add(a);
tree.add(a);
tree.add(a);
const auto& combination = dump( tree );
for_each( combination.begin(), combination.end(), [](string s){ cout << s << endl; } );
}

visual_boost_02

2009-06-03T15:31:02+00:00

O primeiro post do blog foi exatamente este, e não querendo já parecer sessão da tarde e começar a repetir tudo de novo estou re-fazendo o post.

O post original é bem incompleto em vários aspectos, e ao invés de atualizar ele decidi fazer um completamente novo aproveitando que estou configurando uma maquina de build.

Outra vantagem deste artigo é que indo direto a seção “Configurando o Visual”, as informações ali contidas servem para a maioria das bibliotecas de C/C++.

Baixando a Boost

Esta é a etapa mais simples de todas, basta acessar o site oficial, e clicar no link “Download” do lado direito da tela. A versão 1.39.0 (a ultima lançada até o dia que esse artigo foi publicado) pode ser baixada clicando aqui.

No meu caso utilizo a versão zip do pacote, mas todos os outros pacotes acredito que possuam o mesmo conteúdo.

Após o download extraia o conteúdo dos arquivos para o diretório de bibliotecas que você costuma utilizar, no meu caso c:\develop\libs.

Depois de extrair os arquivos é necessário baixar o bjam, que é a ferramenta de compilação da Boost, a ultima versão pode ser encontrada clicando aqui.

Após concluído o download do bjam extraia o arquivo exe para o mesmo diretório em que a Boost foi colocada (no meu caso C:\develop\libs\boost_1_39_0).

Compilando

Agora com as ferramentas prontas é necessário rodar o bjam, para tal acesse o console do Visual Studio (não o console padrão do Windows) clicando em “Iniciar” –> Todos os programas –> Microsoft Visual Studio –> Visual Studio Tools –> Visual Studio 2008 Command Prompt.

Com o console aberto abra o diretório da Boost (no meu caso digito: cd \develop\libs\boost_1_39_0). Dentro do diretório da boost digite “bjam” e ENTER.

Agora como já diz o programa, paciência…

Se tudo correu bem, muitos minutos depois a compilação deve estar completa, as vezes aparecem alguns warnings, que eu simplesmente ignoro.

Configurando o Visual

O jeito mais pratico de configurar o visual na minha opinião é criando uma variável de ambiente que contenha o diretório da Boost, fica mais pratico na hora de atualizar as versões (se não quiser criar a variável, basta ir para o próximo paragrafo), então primeiramente clique em “Iniciar” –> Botão direito em “Meu Computador” –> Propriedades. Na janela que se abrir, clique em “Avançado”, depois no botão “Variáveis de Ambiente”. Na caixa “Variáveis do Sistema”, clique em “Novo”. Agora entre com o nome (ex: BOOST_HOME), e o valor, que é o diretório onde a boost foi instalada (c:\develop\libs\boost_1_39_0 no meu caso), agora é ir clicando em Ok até fechar tudo.

O próximo passo é abrir o visual (se o seu visual já estava aberto e você criou a variável, feche ele e abra novamente). Dentro do visual acesse “Tools” –> “Options”, expanda a linha “Projects and Solutions” –> “VC++ Directories”.

Com a janela de configuração de diretórios podemos configurar os diretórios utilizados pelo visual durante builds, o primeiro a ser configurado é o de include (a ordem não importa aqui), então do lado direito, na caixa de seleção “Show directories for”, selecione “Include Files”. Basta clicar na primeira linha vazia após o ultimo item e entrar com o diretório, que no meu caso foi: $(BOOST_HOME). Caso eu não tivesse criado a variável, o valor teria sido: c:\develop\libs\boost_1_39_0.

Por fim é necessário configurar o diretório de bibliotecas selecionando “Libraries Files” na caixa “Show Directories for” e entrando com o diretório das libs, que no meu caso foi: $(BOOST_HOME)\stage\lib, se não estiver usando a variável, basta então: c:\develop\libs\boost_1_39_0\stage\lib, note que o diretório varia de acordo com o diretório que foi usado na instalação, mas o principal é o sub-diretório “stage\lib”.

Tendo inserido os diretórios, clique em Ok para salvar.

Testando a Instalação

Para testar a instalação crie um novo projeto no Visual (se não sabe como fazer, clique aqui) e use um código exemplo da Boost, eu utilizei o código abaixo:


#include<boost/filesystem/operations.hpp>
#include<iostream>

namespace bf = boost::filesystem;
int main(int, char **)
{
    bf::path p("first.cpp");
    if(bf::exists(p))
        std::cout<<p.leaf()<<"exists.\n";
    else
        std::cout<<p.leaf()<< "does not exist.\n";

    return 0;
}

O código compilou sem problemas aqui e executou perfeitamente, sendo assim, instalação concluída.

Note que a Boost automaticamente já linka o código com as bibliotecas necessárias, com algumas bibliotecas é necessário configurar o arquivo lib a ser usado, mas isso fica para outro post.

0xc0de

2009-05-24T16:17:20+00:00

Alocação de memória é assunto importante em C++. No entanto, nem todo mundo sabe exatamente como as coisas acontecem. Quantos de vocês já não viram códigos carregados de new/delete em situações nas quais objetos de pilha seriam suficientes ou mais indicados?

O livro Exceptional C++ (Herb Sutter) tem vários tópicos sobre gerenciamento de memória. Inclusive, com uma tabelinha bem bacana que descreve as áreas de memória de um programa C++. O detalhe, talvez um pouco polêmico, é que é feita uma distinção entre o heap e o free store (espaço livre para armazenamento). Tentarei explicar.

Creio que todos sabem que a alocação dinâmica é mais cara que na pilha. Ou seja, o uso do new e delete implica em solicitação e devolução de memória ao sistema operacional durante execução do programa. A consequência disso é um preço, em termos de eficiência, maior do que aquele de um objeto criado por valor na pilha. Obviamente, o new é necessário em inúmeros casos. Mas de onde vem essa memória?

Provavelmente, alguns respoderam heap. Outros responderam free store. Há ainda os que dizem que ambos são exatamente a mesma coisa. Então, existe um veredito?

O padrão C++ não utiliza a palavra heap em nenhum momento com relação à memória. Esse termo só aparece no contexto da STL com a conotação da conhecida estrutura de dados. No que diz respeito a alocação dinâmica, está presente apenas o conceito de free store. É de lá que vem a memória dinâmica de um new. Do ponto de vista prático, porém, o free store normalmente corresponde justamente ao que é chamado de heap nos sistemas. Portanto, apesar de certa confusão (ou mal entendido), considero que a forma oficial de se refereir a origem da memória obtida por new seja através de free store. Mas também considero totalmente aceitável que o heap e o free store sejam, de fato, o mesmo lugar.

Uma das origens dessa confusão é que Herb Sutter menciona no livro que o free store é a área de memória dinâmica utilizada por new/delete. Enquanto que o heap é área de memória utilizado pelas funções malloc/free. Não tenho o padrão de C em minhas mãos, mas realmente gostaria de saber se ele utiliza a palavra heap com o significado de área de memória. Por acaso, alguém sabe?

De qualquer maneira, há uma mensagem bem esclarecedora na Intenet em que Bjarne Stroustrup tenta explicar por que foi feita a distinção entre heap e free store por Herb Sutter. De acordo com ele, a idéia era simplesmente deixar claro que uma alocação feita por malloc é diferente de uma alocação feita por new, o que faz sentido total.

Uau… Depois de toda essa discussão deixo um breve resumo da tabela de Exceptional C++ que descreve as 5 áreas de memória de um programa C++. A tabela detalhada também pode ser encontrada em GotW.

const data – Armazena literais de strings e outros valores read-only conhecidos em tempo de compilação, os quais duram durante toda a execução do programa.

pilha – Área de variáveis automáticas.

free store – Memória dinâmica alocada/liberada por new/delete.

heap – Memória dinâmica alocada/liberada por malloc/free.

global/static – Armazena dados globais e estáticos, os quais são inicializados quando o programa começa a executar.

Bom, espero ter sido útil.

Leandro T. C. Melo

Ponteiros e Arrays

2009-05-18T09:08:06+00:00

No primeiro post desta série, falamos um pouco sobre Ponteiros. No segundo, falamos de Referências. Hoje abordaremos a relação íntima (ui!) entre ponteiros e arrays (ou matrizes).

Relembrando Arrays

Um array, ou matriz, ou ainda um arranjo, é uma abstração matemática utilizada para representar um conjunto de dados homogêneos, ou seja do mesmo tipo (int, float, etc). Essa abstração é organizada em formato de tabela, com linhas e colunas. Cada elemento na matriz possui coordenadas únicas (linha e coluna), de forma que um dado elemento E(i,j) representa o único elemento na posição “linha i”, “coluna j”.

A sintaxe de declaração de matrizes segue abaixo:

// Matrizes unidimensionais ou vetores
int     ivet[10];               // 10 elementos, do 0 ao 9
char    cvet[23];               // 23 elementos, do 0 ao 22
 
// Matrizes bidimensionais
int     imat[2][3];             // 2 linhas (0 a 1) e 3 colunas (0 a 2)
double  dmat[10][2];            // 10 linhas (0 a 9) e 2 colunas (0 a 1)

Cada elemento da matriz é independente dos demais e pode ser acessado conforme a sintaxe abaixo:

int ivet[10];
int imat[3][4];
 
// Alterando o quarto elemento do vetor ivet.
// Lembre-se que começa-se a contar a partir do elemento zero
ivet[3] = 13;
 
// Lendo o segundo elemento do vetor ivet
int num = ivet[1];
 
// Alterando o elemento da primeira linha, segunda coluna de imat
imat[0][1] = 42;
 
// Lendo o elemento na terceira linha, quarta coluna de imat
int foo = imat[2][3];

Neste post não vamos discutir a fundo matrizes, vamos apenas investigar a relação entre matrizes e ponteiros de uma forma bastante intuitiva.

Tamanhos de matrizes

Dado que uma matriz é uma abstração que comporta vários valores de um mesmo tipo, qual o tamanho dela? Quanto espaço ele ocupa na memória?

Considere o código abaixo:

int     ivet[10];
char    cvet[13];
double  dvet[20];
 
char    cmat[3][4];
int     imat[5][4];
 
cout << "sizeof(int)     = " << sizeof(int) << endl;
cout << "sizeof(char)    = " << sizeof(char) << endl;
cout << "sizeof(double)  = " << sizeof(double) << endl;
 
cout << "sizeof(ivet)    = " << sizeof(ivet) << endl;
cout << "sizeof(cvet)    = " << sizeof(cvet) << endl;
cout << "sizeof(dvet)    = " << sizeof(dvet) << endl;
cout << "sizeof(cmat)    = " << sizeof(cmat) << endl;
cout << "sizeof(imat)    = " << sizeof(imat) << endl;

O resultado é bastante razoável. O Espaço ocupado por uma matriz é igual ao número de elementos multiplicado pelo tamanho do tipo do elemento (linhas x colunas x sizeof(tipo)). Ora, se cada elemento é independente, supõe-se que cada um ocupe um lugar separado na memória, caso contrário um elemento sobrescreveria outro. Sendo assim, será que cada elemento possui seu próprio endereço de memória?

Matrizes e endereços de memória

Para facilitar, vamos então analisar os possíveis endereços de uma matriz de caracteres, cujo tamanho de um dado único é 1 byte:

const int max = 5;
char cvet[max] = {'A', 'B', 'C', 'D', 'E'};
 
// Mostrando o índices, valores e endereços dos dados.
printf("Índice\tValor\tEndereço do elemento\n");
for (int i = 0; i < max; i++) {
    printf("%d\t%c\t%p\n", i, cvet[i], &cvet[i]);
}
 
// Mostrando o endereço da própria matriz
printf("Endereço da matriz: %p\n", &cvet);
 
// Mostrando o endereço da própria matriz denovo
printf("Endereço da matriz: %p\n", cvet);

Os endereços dos elementos são sequenciais, ou seja, cada elemento é armazenado ao lado do anterior. Adicionalmente existem dois fatos ainda mais interessantes:

O endereço do array (&cvet), mostrado na linha 25, é o mesmo do primeiro elemento do array;
A própria variável cvet pode ser interpretada como um ponteiro, como é mostrado na linha 28;

Em C++, um array comum é um bloco contíguo de memória cujo nome pode ser interpretado (cast) como um ponteiro que aponta para o seu primeiro elemento. Adicionalmente é válido fazer um ponteiro apontar para um array desde que o ponteiro destino seja para o mesmo tipo que o tipo dos elementos do array. Durante a atrubuição de um array a um ponteiro, o compilador faz uma conversão implícita de tipos. O ponteiro destino passa a ser interpretado como um ponteiro para a área de memória ocupada pelo array.

Uma das consequências não tão óbvias é que durante o cast implícito, é perdida a informação de que aquela área de memória era um array. Portanto é perdida a informação do tamanho do array. Do ponto de vista do ponteiro, ele está apontando para o começo de um bloco arbitrário de memória, de um tamanho também arbitrário. Sair de um array e ir para um ponteiro significa ir de uma abstração mais restritiva e mais alto nível, para um abstração menos restritiva e mais baixo nível.

Por outro lado tentar atribuir um ponteiro a um array gera um erro de compilação por tipos incompatíveis. Um array é um bloco de memória de n dados (bytes), já um ponteiro possui apenas um dado, um endereço. O compilador não tem como saber de antemão se um ponteiro aponta para uma área de 1, 2 ou 200 bytes.

const int max = 300;
char cvet[max];
char* pc = 0;
 
printf("\nAntes da atribuição\n");
printf("cvet = %p\n", cvet);
printf("pc   = %p\n", pc);
printf("sizeof(cvet) = %lu\n", sizeof(cvet));
printf("sizeof(pc)   = %lu\n", sizeof(pc));
 
pc = cvet;
 
printf("\nDepois da atribuição\n");
printf("cvet = %p\n", cvet);
printf("pc   = %p\n", pc);
printf("sizeof(cvet) = %lu\n", sizeof(cvet));
printf("sizeof(pc)   = %lu\n", sizeof(pc));

Note que antes da atribuição (linha 25) o ponteiro pc. está nulo, pois foi inicializado assim. Já os tamanhos indicam que o array possui 300 bytes e o ponteiro apenas 8 (minha máquina é um amd 64). Após a atribuição ambos passam a “apontar” para a mesma área de memória, porém os tamanhos não mudam. Houve um cast implicito de char[300] para char*, e nessa brincadeira o ponteiro pc não tem como saber o tamanho da área de memória para o qual ele aponta. Já o array cvet continua sabendo direitinho o que ele é, sem nenhuma crise existencial.

Aritmética de ponteiros – Vulgo, e daí?

Ora, mas se eu sei que os dados numa matriz estão dispostos lado a lado, eu posso utilizar um ponteiro que vai pulando para o endereço ao lado e acessando o elemento seguinte. O nome disso é aritimética de ponteiros.

const int max = 6; 
char cvet[max] = {'B','L','A','B','O','S'};
 
char* pc = cvet;
 
for (int i = 0; i < max; i++) {
    printf("%c", *(pc + i));
}
printf("\n");
 
for (int i = 0; i < max; i++) {
    printf("%c", *pc++);
}
printf("\n");
 
 
// Agora com inteiros
int ivet[max] = {1, 2, 3, 4, 5, 6};
int* pi = ivet;
 
for (int i = 0; i < max; i++) {
    printf("%p = %d\n", pi, *pi++);
}
printf("\n");
 
// Em duas dimensões
char cmat[2][3] = {{'B','L','A'},{'B','O','S'}};
char* ppc;
 
ppc = (char*)cmat;
 
for (int i = 0; i < 2; i++) {
    for (int j = 0; j < 3; j++) {
        printf("%c", *(ppc + 3*i+j));
    }
    printf("\n");
}
printf("\n");

Na linha 18 o ponteiro pc passa a pontar para o array cvet, e consequentemente para o seu primeiro elemento, o caracter ‘B’. Na linha 21 o conteúdo de pc, que é o endereço onde foi armazenado o caracter ‘B’, é incrementado de i e em seguida de-referenciado. Na primeira passada o valor de i é zero, portanto é dereferenciado para o valor ‘B’. Nos passos seguintes, o endereço seguinte vai sendo de-referenciado para os outros caracteres armazenados no array original. É mais ou menos isso que internamente o compilador faz quando você utiliza a sintaxe cvet[i]. A abstração de array te dá uma forma mais amigável de tratar áreas contíguas de memória do que *(pc + i).

Mas se a abstração de array é mais simples, pra que utilizar aritmética de ponteiros?

Uma das respostas está a linha 26. Ela faz a mesma coisa que a linha 21, porém um pouco mais rápido. Na sintaxe da linha 21, ou de forma semelhante, na sintaxe de array, o acesso a um dado qualquer pode ser resumido de forma bem grosseira nos comandos:

Tome o endereço base do array;
Adicione ao endereço o valor do índice;
De-referencie este novo endereço;

Já com aritmética de ponteiro ficaria assim:

De-referencie este endereço;

O comando incremento (ou a conta feita com endereços) não vou contar porque é parte do loop, embora i++; seja mais rápido que a = b + c;. Agora imagine esse pequeno ganho de 66% aplicado em uma área de dados de 1 MB. Serão mais de 2 milhões de comandos a menos!

A técnica de utilizar um ponteiro para manipular uma área arbitrária de memória é utilizada geralmente em programação de baixo nível (mais próximo da máquina), manipulação de buffers e strings, entre outros truques sujos. Nas entranhas dos computadores, operações que varrem extensas áreas de memória, frequentemente são realizadas com aritimética de ponteiros. Nesse nível, Darwin reina supremo e só os mais preparados sobrevivem. A partir daqui a linguagem começa a dar um poder que só os puros de coração conseguem compreender.

Uma observação importante é que entre as linhas 31 e 38 a experiência é repetida com inteiros. Note que como os inteiros possuem 4 bytes, os incrementos são automaticamente feitos de 4 em 4 bytes, e não de 1 em 1, ou seja o incremento é automaticamente calculado para sizeof(tipo). Incrementar um ponteiro significa acessar a próxima área de memória semelhante ao dado atual, e não apenas o próximo endereço. Como o tamanho de um char é um byte, quando incremetamos um ponteiro para char, avançamos apenas 1 byte. Se incrementarmos um ponteiro para double, avançaremos 8 bytes, e assim por diante.

Outra observação é que uma matriz bidimensional pode ser “linearizada” conforme é mostrado nas linhas 40 a 52. Isso é útil, quando aplicável, para aproveitar melhor o cache do processador, por exemplo.

void*, o Pansexual dos ponteiros

Anteriormente eu disse que só era possível atribuir um array a um ponteiro que fosse para o mesmo tipo que os dados do array. Eu menti descaramente! O motivo, é que para alguém que desistiu do post antes deste tópico, é mais seguro acreditar que não pode !

Existem duas exceções à regra. A primeira é quando há uma conversão explícita de tipos e o ponteiro destino “acha” que está apontando para o tipo certo. Um exemplo está na linha 44 do código anterior.

A segunda é o caso dos ponteiros para void. Um ponteiro para void é um ponteiro que não faz exigências quanto ao tipo de dados que está na área de memória para o qual ele aponta. Ele é um ponteiro pra uma área genérica de memória, algo bem baixo nível.

Para utilizar um dado apontado por um ponteiro para void, antes de de-referenciá-lo, é preciso fazer um cast explícito para algum tipo válido, pois se um int* é de-referenciado para int e um char* é de-referenciado para char, adivinhe para que é de-referenciado um void*?

const int max = 6; 
char cvet[max] = {'B','L','A','B','O','S'};
 
void* pv = cvet;
 
// Erro de compilação.
//*pv
// Quanto vale sizeof(void)?
 
for (int i = 0; i < max; i++) {
    printf("%c", *(((char*)pv) + i));
}
printf("\n");

Ponteiro para void são utilizados quando precisa-se apontar para uma área genérica de memória sem ter controle/conhecimento do tipo de dados que essa área contém, ou em funções que não podem fazer suposições sobre os tipos de seus parâmetros, como é o caso da API da lib pthreads (link arbitrário).

Encerrando

Quanto mais nos aprofundamos nos tópicos sobre ponteiros, mais próximos da máquina ficamos. Boa parte do poder das linguagens C e C++ provém daí, e boa parte dos problemas também. A complexidade vai aumentando e os riscos também. Para muitos é aí que mora a diversão!

Links

If you liked this post, buy me a beer

Comma Quibbling Puzzle

2009-05-08T13:12:15+00:00

Some days ago (almost one month ago), Eric Lippert post a cool puzzle.

I did some solutions, to be exact, one in C++ and 2 in C#. So, today I had time to compile them here...

C++ Solution:

#include

<algorithm>
#include <string>
#include <sstream>
#include <iostream>
#include <vector>
#include <iterator>

using namespace std;

namespace Solution
{
  template< class Elem, class TString = basic_string<Elem>, class TSequenceContainter = vector<TString> >
  class GetSequence
  {
    TString Open_, Close_, Separator_, Separator_End_;
    int min( int lVal, int rVal ){ return lVal < rVal ? lVal : rVal; }
  public:
    GetSequence(TString open, TString close, TString separator, TString separator_end) :
    Open_(open), Close_(close), Separator_(separator), Separator_End_(separator_end){}
    TString get(const TSequenceContainter& items)
    {
      TSequenceContainter::size_type itemsCount = items.size();
      typedef ostream_iterator<TString, Elem> iter;
      basic_stringstream<Elem> ss;
      ss << Open_;
      copy( items.begin(), items.end() - min(2, itemsCount), iter( ss, Separator_.c_str() ) );
      copy( items.end() - min(2, itemsCount), items.end() - min(1, itemsCount), iter( ss, Separator_End_.c_str() ) );
      copy( items.end() - min(1, itemsCount), items.end(), iter( ss ) );
      ss << Close_;
      return ss.str();
    }
  };

  GetSequence<char> seq_ASCII(){ return GetSequence<char>("{", "}", ", ", " and "); }
  GetSequence<wchar_t> seq_Unicode(){ return GetSequence<wchar_t>(L"{", L"}", L", ", L" and "); }
}

int main()
{
  vector<string> x;
  x.push_back("A");
  x.push_back("B");
  x.push_back("C");
  x.push_back("D");

  cout << Solution::seq_ASCII().get( x ) << "\n";

  vector<string> y;
  y.push_back("A");
  y.push_back("B");

  cout << Solution::seq_ASCII().get( y ) << "\n";

  vector<string> z;
  z.push_back("A");

  cout << Solution::seq_ASCII().get( z ) << "\n";
  vector<string> w;

  cout << Solution::seq_ASCII().get( w ) << "\n";
  vector<wstring> ux;
  ux.push_back(L"A");
  ux.push_back(L"B");
  ux.push_back(L"C");
  ux.push_back(L"D");

  wcout << Solution::seq_Unicode().get( ux ) << L"\n";

  vector<wstring> uy;
  uy.push_back(L"A");
  uy.push_back(L"B");

  wcout << Solution::seq_Unicode().get( uy ) << L"\n";
  vector<wstring> uz;
  uz.push_back(L"A");

  wcout << Solution::seq_Unicode().get( uz ) << L"\n";
  vector<wstring> uw;
  wcout << Solution::seq_Unicode().get( uw ) << L"\n";
}

C# Solutions:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

static class Solution
{
static StringBuilder Append(this StringBuilder sb, string one, string two) { return sb.Append(one).Append(two); }
static string Next(this IEnumerator<string> enumerator) { enumerator.MoveNext(); return enumerator.Current; }
public static string GetSequence(IEnumerable<string> items)
{
    const string OPEN = "{", CLOSE = "}";

    //(1) If the sequence is empty then the resulting string is "{}"
    if (null == items)
      return OPEN + CLOSE;

    int itemsCount = items.Count();
    switch (itemsCount)
    {
      //(1) If the sequence is empty then the resulting string is "{}"
      case 0:
        return OPEN + CLOSE;
      //(2) If the sequence is a single item "ABC" then the resulting string is "{ABC}"
      case 1:
        return OPEN + items.First() + CLOSE;
      //(3) If the sequence is the two item sequence "ABC", "DEF" then the resulting string is "{ABC and DEF}".
      //(4) If the sequence has more than two items, say, "ABC", "DEF", "G", "H" then the resulting string is "{ABC, DEF, G and H}". (Note: no Oxford comma!)
      default:
        const int COUNTDOWN = 2, ESTIMATED_STRING_LENGTH = 4;
        const string SEPARATOR = ",", SEPARATOR_END = "and";
        var sb = new StringBuilder(OPEN, ESTIMATED_STRING_LENGTH * itemsCount);
        var enumerator = items.GetEnumerator();
        while (COUNTDOWN < itemsCount--)
          sb.Append(enumerator.Next(), SEPARATOR).Append(" ");
        return sb.Append(enumerator.Next(), " ").Append(SEPARATOR_END, " ").Append(enumerator.Next(), CLOSE).ToString();
    }
  }
}

static class Solution2
{
  static string Match(this IEnumerable<string> items, params Func<string>[] funcs)
  {
    return funcs[null == items ? 0 : Math.Min(items.Count(), funcs.Length - 1)]();
  }

  public static string GetSequence(IEnumerable<string> items)
  {
    return items.Match
    (
      () => { return "{}"; },
      () => { return "{" + items.First() + "}"; },
      () =>
      {
        int count = items.Count() - 2;
        var sb = new StringBuilder("{");
        foreach (var item in items.Take(count))
          sb.Append(item).Append(", ");
        var last = items.Skip(count).ToArray();
        sb.Append(last[0]).Append(" and ").Append(last[1]);
        return sb.Append("}").ToString();
      }
    );
  }
}

class TestProgram
{
  static void Main()
  {
    Action<string> print = Console.WriteLine;
    print( Solution.GetSequence(new string[] { "A", "B", "C", "D" }) );
    print( Solution.GetSequence(new string[] { "A", "B" }) );
    print( Solution.GetSequence(new string[] { "A" }) );
    print( Solution.GetSequence(new string[] {}) );
    print( Solution.GetSequence(null) );

    print(new string('-',20));

    print(Solution2.GetSequence(new string[] { "A", "B", "C", "D" }));
    print(Solution2.GetSequence(new string[] { "A", "B" }));
    print(Solution2.GetSequence(new string[] { "A" }));
    print(Solution2.GetSequence(new string[] { }));
    print(Solution.GetSequence(null));
  }
}

Últimas pesquisas na blogosfera nacional

2009-05-08T10:50:40+00:00

É um imenso prazer constatar que hoje, mais de dez anos depois de eu ter iniciado minha caminhada pelo mundo da programação C/C++, temos uma reação de blogues e saites prontos para elucidar questões simples e avançadas dessas duas linguagens que ainda não morreram e, se depender de como as coisas andam, ainda vão durar pelo menos mais uns dez anos (sim, não sou tão otimista assim).

Esse artigo é só para constar em minha lista de referência para o aprendizado de C, C++ e todas as outras coisas que vem depois. Se eu tivesse que escrever isso lá no início, provavelmente recomendaria mais linques de livros e saites em inglês. Hoje, felizmente, temos um conteúdo em pleno desenvolvimento em nossa blogosfera tupiniquim. E espero que continue assim!

C/C++

Visual Studio

Mais assuntos?

A internet brasileira cresceu como um todo. Mesmo que você deseje saber mais sobre microprocessadores ou drivers para Windows, em português, hoje isso é possível. É claro que o que não é possível é você se dedicar profissionalmente a essas áreas sem saber inglês. Mas é uma muito bem-vinda manifestação das pessoas que fazem acontecer todas essas coisas em nosso país.

Ponteiros e referências em C++ parte 2

2009-05-02T06:32:51+00:00

Continuando com essa tentativa de série de posts sobre ponteiros e referências, que começou falando sobre Ponteiros, hoje abordaremos Referências.

Uma referência é um nome alternativo para um objeto, um alias. Aliás, quem diz isso não sou eu, mas o próprio Bjarne Stroustrup, lá pelo tópico 5.5 do seu livro, cujo conteúdo é tão bom que só fui reparar hoje que na capa tem uma onda quebrando em forma de C. Gostei dessa capa!

Declarando Referências

Uma referência para um determinado tipo é declarada acrescentando-se o caracter & (ê comercial ou ampersand) após o nome do tipo da referência. Note que da mesma forma que na declaração de ponteiros, estamos tratando o & como um caracter de notação e não um operador. Não há um operador de declaração de ponteiros ou referências. É apenas uma notação da linguagem. Dado um tipo T, a expressão T& significa Referência para T. Por exemplo:

// Declara uma variável inteira original.
// Também poderia ser char, float, etc.
int i;
 
// Declaram referências para a variável i.
// Todas as formas são equivalentes, mas preferimos a primeira.
// Note que os tipos das referências tem que ser os mesmos
// que os das variáveis referenciadas.
int& ra     = i;
int &rb     = i;
int & rc    = i;
 
// Diferentemente de ponteiros, a linha abaixo gera um
// erro de compilação. Você saberia dizer por quê?
int &r1, &r2;

Embora em C++ as referências lembrem um pouco os ponteiros, eles são bem diferentes. Ao contrário do que acontece com ponteiros, uma referência precisa ser inicializada durante sua declaração. Tentar declarar uma referência sem inicializá-la gera um erro em tempo de compilação, ou seja, o compilador vai cuspir na sua cara “Perdeu playboy, perdeu!”. A única exceção a essa regra é para referências declaradas como extern, pois elas serão inicializadas em algum outro ponto do programa, mas isso é outro papo.

Se você tentar trapacear declarando uma referência extern sem inicializá-la o compilador não vai reclamar. Se ela nunca for utilizada, ok. Se o compilador for esperto e notar que ela não será utilizada, pode até removê-la da lista de símbolos. Mas se ela for utilizada em qualquer parte do programa, o linker vai rir da sua cara gargalhando “undefined reference to ‘nome_da_variavel’”. Portanto faça as coisas direitinho. Declarou uma referência? Então iniclalize-a. extern? Tem certeza que sabe o que está fazendo?

A lógica por trás disso é que uma referência foi planejada para ser um nome para alguma coisa. Se você não a inicializar, ela não será nome para nada, então não faz sentido. Um detalhe muito importante é que inicializar uma referência não é atribuir um valor a ela. Como o prório Bjarne diz, nenhum operador opera sobre referências, ou seja, não há como atribuir, somar, subtrair, etc com uma referência. Como uma referência é um apelido para um objeto, cada operador atua nese objeto, e não na referência. Uma vez inicializada, uma referência sempre referenciará o mesmo objeto.

A primeira armadilha com referências, assim como ponteiros está na questão do tamanho. Enquanto o tamanho de um ponteiro (e de outras estruturas de dados) pode ser obtido com o operador sizeof, o tamanho de uma referência não pode ser obtido por técnicas convencionais, já que ao aplicar o operador sizeof em uma referência, estamos na verdade, aplicando o operador no objeto ao qual ela se referencia, conforme vimos no parágrafo anterior.

char    c;
int     i;
double  d;
 
char&   rc = c;
int&    ri = i;
double& rd = d;
 
// O operador sizeof diz o tamanho do tipo do seu argumento.
cout << "Size of char:    " << sizeof(c) << " bytes" << endl;
cout << "Size of int:     " << sizeof(i) << " bytes" << endl;
cout << "Size of double:  " << sizeof(d) << " bytes" << endl;
 
cout << endl;
 
cout << "Size of char&:   " << sizeof(rc) << " bytes" << endl;
cout << "Size of int&:    " << sizeof(ri) << " bytes" << endl;
cout << "Size of double&: " << sizeof(rd) << " bytes" << endl;

As técnicas para obter os tamanhos das referências fogem ao escopo deste texto, mas pretendo falar sobre elas futuramente. Por hora, vou apenas dizer sem demonstrar que, quando aplicável, o tamanho de uma referência é idêntico ao tamanho de um ponteiro.

A parte boa da história é que frequentemente os tamanhos de ponteiros e referências são bem menos relevantes que os tamanhos dos objetos apontados ou referenciados. Eu particularmente, nunca precisei utilizar essa informação, mas para o desenvolvimento em arquiteturas diferentes ou para sistemas embarcados, isso já se torna mais interessante.

Utilizando Referências

O uso de referências já é bem mais simples que o de ponteiros, pois não são necessários operadores de extração de endereços ou de de-referenciação. Variáveis referências são utilizadas como variáveis comuns, lembrando que uma operação feita numa referência sempre afeta o objeto referenciado.

int x, y;
int& rx = x;
int& ry = y;
 
x = 13;
y = 10;
 
rx = 42;    // A atribuição é automaticamente aplicada em x.
ry++;       // O incremento é automaticamente aplicado em y.
 
cout << "x:  " << x << endl;    // Valor de x.
cout << "y:  " << y << endl;    // Valor de y.
cout << "rx: " << rx << endl;   // Valor de rx == x.
cout << "ry: " << ry << endl;   // Valor de ry == y.

Utilizar uma referência é tão transparente para o programador, que ele nem precisa saber que é uma referência. Simplesmente usa como se fosse uma variável ordinária. Com minha imaginação limitada não vejo como alguém consiga ser excomungado por utilizar referências inadequadamente. Embora sempre tenha algum espírito de porco que consiga fazer merda com referências, é muito mais fácil levar rasteira de Saci ao manusear ponteiros.

Endereços e Referências

Do ponto de vista de Murphy, as referências são feias, chatas e bobas, pois existe pouca coisa potencialmente perigosa a se fazer com elas. Nem mesmo quanto a endereçamento há muitas surpresas (será?). Considere o código abaixo:

int a = 10;
int b = 13;
 
int& ra = a;
int& rb = b;
 
ra = 42;
rb = 7;
 
cout << "ra  = " << ra << endl;// O valor de ra == 42.
cout << "rb  = " << rb << endl;// O valor de rb == 7.
cout << "a   = " << a << endl; // O valor de a == ra == 42.
cout << "b   = " << b << endl; // O valor de b == rb == 7.
 
cout << "&a  = " << &a << endl; // O endereço de a.
cout << "&b  = " << &b << endl; // O endereço de b.
cout << "&ra = " << &ra << endl;// O endereço de ra == &a. 
cout << "&rb = " << &rb << endl;// O endereço de rb == &b.

Nas linhas 17 e 18 eu declaro duas variáveis inteiras (poderia ter feito esse exemplo com uma só…). Nas linhas 20 e 21 eu declaro duas referências, referenciando as duas variáveis anteriores. A partir desse momento as variáveis ra e rb são apenas apelidos para as variáveis a e b. Como vimos anteriormente, qualquer operador aplicado às referências, na verdade atua nos objetos referenciados, portanto cada par variável-referência possui sempre o mesmo valor.

A parte interessante a se notar é que os endereços das referências são exatamente os mesmo endereços das variáveis que elas referenciam, ao contrário dos ponteiros que tinham seus próprios endereços. Por quê? Porque você caiu na Pegadinha do Malandro. Lembra daquele papo de nenhum operador ser aplicável a uma referência? Pois bem, o & utilizado aqui é o operador “endereço de”, que também é aplicado diretamente nas variáveis originais e não nas referências. As mesmas técnicas ninja utilizadas para obter os tamanhos das referências são necessárias para se obter os endereços delas.

Novamente a parte divertida disso é que o mecanismo de referências foi planejado para ser o mais transparente possível para o programador. Tamanhos e endereços físicos de referências são informações irrelevantes do ponto de vista da programação “normal” em C++.

Diferenças e semelhanças entre Ponteiros e Referências

Tanto ponteiros como referências são mecanismos de indireção em C++, ou seja, são mecanismos utilizados para que a partir de um dado símbolo (variável) eu seja capaz de manipular outro objeto.

Os principais usos para ponteiros são geralmente relacionados com gerenciamento e manipulação dinâmica de memória, criação e destruição de objetos de formas e em momentos especiais, bem como “passagem de parâmetros por referência” (assim entre aspas mesmo). Já as referências são mais utilizadas em passagem por referência (por que será?) e sobrecarga de operadores.

Basicamente, tudo que podemos fazer com referências pode ser emulado com ponteiros. Já a recíprocra não é sempre verdadeira. A grande vantagem delas no entanto, é o fato de tornarem a indireção completamente transparente ao programador.

Uma alegoria interesante para ajudar a entender melhor as diferenças entre ponteiros e referências é o apelido. Por exemplo: Imagine que um pessoa, digamos, Carlos Caetano Bledorn Verri, seja a nossa variável original, o objeto. Dunga já é uma referência a Carlos Caetano Bledorn Verri, pois é um apelido para o mesmo objeto, são a mesma pessoa. Já a Mãe do Dunga (ou do Carlos Caetano Bledorn Verri, tanto faz), que é contantemente citada pela torcida, pode ser considerada um ponteiro para ele, pois dados determinados operadores de vocabulário, um elogio feito a ela, na verdade é indiretamente direcionado a ele.

O Java e o MySQL passam a ser da Oracle

2009-04-30T02:51:31+00:00

A compra da Sun pela Oracle concluída no domingo (19/04) e anunciada na semana passada (20/04) pegou de surpresa os desenvolvedores de todo o mundo. Negociada em US$ 7,4 bilhões, em meio a “crise” (que, cá entre nós, não assustou o setor de T.I.), a Sun finalmente cedeu à oferta. Fora a negociação, o que mais tem deixado a comunidade de cabelo em pé é a questão: como fica o suporte ao MySQL,

TDD na Prática – Parte V: Testabilidade e a UML

2009-04-11T07:43:02+00:00

Seguindo nossa pequena série sobre TDD, vamos ver sobre como a testabilidade influencia no design, sobre a diferença de escrevermos os testes antes ou depois e como a UML pode se relacionar com TDD. (Lembrando que nas próximas partes da série será dado início à implementação de um pequeno e simples Jogo da Velha, nos moldes do TDD) Como podemos testar um Jogo da Velha ? O que deve ser

Qt com licença LGPL

2009-04-11T05:07:26+00:00

A Nokia decidiu permitir a adoção da Lesser General Public License (LGPL) versão 2.1 opcionalmente à GPL 3 para seu framework de construção de interfaces gráficas para desktop e dispositivos portáveis, o Qt. A Qt 4.5, liberada ontem, já saiu com esta licença. Na prática, significa que a versão do framework poderá ser usada para fins comerciais e assim mais pessoas e empresas se interessarão a

Revistas: ESM edições 1 e 2

2009-04-11T04:59:36+00:00

Para quem gosta de ler artigos relacionados à Engenharia de Software, aí vão duas edições gratuitas da Engenharia de Software Magazine, da editora DevMedia, disponíveis para download. Edição 1 Download em baixa resolução Download em alta resolução Edição 2 Download

The Anagram problem (and a sequential solution)

2009-03-09T13:52:15+00:00

This is a sequential solution using C++ of anagram problem pointed out by Eric Lippert's Fabulous Adventures In Coding

The solution itself is multi-paradigm and platform independent (except in the case of StopWatch which is Windows specific, but could be easily ported).

The file used as dictionary to test is an adapted version of twl06.txt (is the same file only with the words, without the numbers and space). This file could be searched by your preferred search engine.

#include <iostream>
#include <fstream>
#include <vector>
#include <set>
#include <algorithm>
#include <iterator>
#include <functional>
#include <cstring>
#include <string>

using namespace std;

#define WIN32_LEAN_AND_MEAN

#include <windows.h>

string Canonicalize( const string& str_value )
{
string canonicalizedValue( str_value );
sort( canonicalizedValue.begin(), canonicalizedValue.end() );
return canonicalizedValue;
}

void RecursiveReplace( const string& value, set<string>& canonicalizedValues )
{
  string::size_type idx( value.find_first_of( '?' ) );
if( idx == string::npos )
{
    canonicalizedValues.insert( Canonicalize( value ) );
    return;
}

string value_( value );
for(char ch = 0x41; ch <= 0x5A; ++ch)
{
    value_[ idx ] = ch;
    RecursiveReplace( value_, canonicalizedValues );
}
}

struct CanonicalizedValues
{
CanonicalizedValues( const string& value ) : OriginalValue_( value )
{
    RecursiveReplace( value, CanonicalizedValues_ );
}

const set<string>& GetValues() const
{
return CanonicalizedValues_;
}

const string& GetOriginalValue() const
{
return OriginalValue_;
}

private:
set<string> CanonicalizedValues_;
string OriginalValue_;
};

struct FindMatches
{
FindMatches( const CanonicalizedValues& canonicalizedValues, vector<string>& result )
    : CanonicalizedValues_( canonicalizedValues ),
      Result_( result ),
      WordLength_( canonicalizedValues.GetOriginalValue().length() )
{
}

void operator()( const char* line )
{
    if( WordLength_ == strlen(line) )
    {
      const set<string>& values( CanonicalizedValues_.GetValues() );
      const string canonicalizedValue( Canonicalize( line ) );
      if( values.end() != find( values.begin(), values.end(), canonicalizedValue ) )
      {
        Result_.push_back( line );
      }
}
}

private:
const CanonicalizedValues& CanonicalizedValues_;
vector<string>& Result_;
size_t WordLength_;
};

template<class Function>
void ReadLines( const char* filename, Function _Func )
{
const int MAX_LINE_SIZE = 30;
char line[MAX_LINE_SIZE];

ifstream file( filename );

while( file.getline( line, MAX_LINE_SIZE, '\n' ) )
    _Func( line );

file.close();
}

struct StopWatch
{
StopWatch()
{
    ::QueryPerformanceFrequency( &Freq_ );
}

void Start()
{
    ::QueryPerformanceCounter( &Start_ );
}

void End()
{
::QueryPerformanceCounter( &End_ );
    End_.QuadPart -= Start_.QuadPart;
}

__int64 ElapsedTicks()
{
    return End_.QuadPart;
}

double ElapsedTime()
{
    return static_cast<double>(ElapsedTicks()) / Freq_.QuadPart;
}

private

:
LARGE_INTEGER Freq_, Start_, End_;
};

int main()
{
vector<string> result;
StopWatch sw;

sw.Start();

//CanonicalizedValues values( "AALNSTI?" );
CanonicalizedValues values( "A????" );
//CanonicalizedValues values( "AALNST?" );

ReadLines
(
    "C:\\Users\\Fabio Galuppo\\Documents\\twl06_adapted.txt",
    FindMatches
    (
      values,
      result
    )
);

sw.End();

copy( result.begin(), result.end(), ostream_iterator<string>( cout, "\n" ) );

cout << "Count = " << result.size() << "\n" << "Elapsed Time (s) = " << sw.ElapsedTime() << "\n" << "Elapsed Ticks = " << sw.ElapsedTicks() << "\n";
}

Next time, I'll (hope to) improve the sample to reading (applying lambdas and others C++0x features) and performance (using concurrency features - probably a boost threads approach and PPL approach).

TDD na Prática - Parte IV: Quem, Onde, Quando, O Que e Como

2009-03-08T21:13:15+00:00

Após um breve exercício de análise, você faz um levantamento das tarefas que precisará fazer para concluir a criação de uma determinada funcionalidade no software. Desta funcionalidade, tanto você como o usuário para o qual o software se destina, pode estabelecer as condições mínimas necessárias para que o software seja considerado "satisfatório". Estas condições poderão fazer parte do

Funcionamento dos frameworks xUnit - Parte 2/2

2009-03-06T22:24:20+00:00

Para complementar o descrito na Parte 1, vamos ver o uso de test fixtures e dos métodos setUp e tearDown. Em muitos casos quando estamos construindo uma classe de testes para verificar determinada funcionalidade, diversos métodos de teste irão operar sobre um mesmo objeto ou conjunto de objetos. Ao escrevermos código para configurar o estado destes objetos repetidamente, em cada método de

Google Mock

2009-03-06T22:08:12+00:00

A Google liberou seu C++ Mock Framework sob a nova licensa BSD, complementando seu Google C++ Testing Framework (ou somente Google Test). Ao que me parece, eles fizeram um trabalho bem completo, deixando o framework flexível e fácil de usar.O Google Mock é baseado no EasyMock, no jMock e no Hamcrest, sendo construído para C++ sob o Google Test. Para utilizá-lo você precisará, além do Google Test

Funcionamento dos frameworks xUnit - Parte 1/2

2009-03-06T22:06:39+00:00

Durante a série de artigos sobre TDD, tenho citado o uso de frameworks de testes unitários baseados na JUnit. Os exemplos que serão exibidos durante a série partem do princípio que o leitor conhece o funcionamento de um framework xUnit.Sendo assim, coloco aqui uma explicação breve sobre a estrutura da maioria destes frameworks, de forma a facilitar o entendimento dos próximos artigos.Os chamados

POSIX/C++

2009-02-28T17:04:06+00:00

No final de 2007, o IEEE aprovou a criação do projeto "POSIX-C++ Binding", com o propósito de aumentar a portabilidade de programas C++ que façam uso das interfaces de sistema especificadas em POSIX.

Este grupo de trabalho foi "fretado" inicialmente para entregar seu produto em Dezembro de 2011.

Discussões ocorrem em uma lista de discussão pública.

Os trabalhos iniciais envolveram a adequação da nova biblioteca de threads, componente da biblioteca padrão do C++0x, e especificar sua implementação sobre as interfaces de sistema especificadas em POSIX.

Dois outros projetos estão atualmente em discussão: bindings C++ para as interfaces de sockets, e bindings C++ para as interfaces do ligador dinâmico.

Eu estou trabalhando no projeto de bindings C++ para as interfaces de sockets; mais informações podem ser obtidas aqui. Meu trabalho está acontecendo sob a bandeira do Grupo de Usuários de C e C++ do Brasil.

Na próxima reunião do grupo de trabalho, dia 07 de Março, esses dois projetos serão tema da pauta de discussão. Infelizmente eu ainda não obtive um visto para participar dessa reunião; com sorte isso será possível.

O objetivo da binding para as interfaces de socket é basicamente produzir uma classe que aplique as técnicas de gerência de recurso em C++ no projeto de uma classe que represente um socket. Outros objetivos são melhorar a utilização das estruturas de dados representativas de endereços de socket, o uso de atributos de socket e das interfaces de tradução de nomes.

Ao longo deste processo se tornou claro que seria útil acrescentar às estruturas de dados simples especificadas em POSIX elementos como construtores e sobrecargas de operadores, para tornar mais simples e mais eficiente a inicialização de objetos destes tipos e sua operação.

Estou prestes a publicar agora meus primeiros trabalhos nesse sentido, na forma de uma modificação da GNU libc, usável com o GCC 4.4. Informações estão na mesma página mencionada acima.

Glossário Rápido

2009-02-27T23:42:07+00:00

Eu não espero reinventar a roda e ter que explicar todos os conceitos, metodologias, processos, siglas, etc. que surgirem neste blog. Diversos outros autores já reservaram seu tempo fazendo isso. Meu intuito aqui é prover uma definição suscinta para quem não quer ler todo o conteúdo encontrado no Wikipedia ou no site mais próximo, encontrado talvez numa pesquisa no Google. Metologias Ágeis

Win32: sincronização parte 2

2009-01-30T13:17:58+00:00

Preparando esse post eu percebi que o post de sincronização parte 1 não explica nada sobre sincronização, só apresenta o problema que a sincronização resolve. Estou parecendo aqueles vendedores de empresas de software que gastam mais tempo tentando provar que você tem um problema do que realmente mostrando a solução. Agora chegou a hora de mostrar a solução. :-)

Como vimos na primeira parte, o maior problema em programação multithread é o compartilhamento de dados entre as threads. Existem duas solução para isso. A primeira e mais usada é sincronizar o acesso aos dados, de forma que somente uma thread por vez manipule os dados em questão. Ou seja, a solução envolve "eliminar" (notou as aspas?) o multithread da parte que ele atrapalha. A segunda e pouco usada opção é eliminar o compartilhamento dos dados, usando filas, controle restrito de ownership e trabalhando com cópias do dados. Esse é o enfoque usado pelo Erlang, uma nova linguagem de programação.

A forma mais básica para sincronização em vários SOs é o critical section. Esse recurso permite definir um trecho de código que é executado por várias threads, mas que precisa ser sincronizado entre elas. Sincronizado == somente uma thread pode executar esse trecho de código por vez.

Revisando a nossa classe de lista ligada, vamos ver quais são os dados da classe:

template<typename T>

class LinkedList
{
  struct NODE
  {
    NODE* previous;
    NODE* next;
    T data;
  };
 
  NODE rootNode_;
  unsigned int count_;

 ...

A princípio parece que precisamos sincronizar o rootNode_ e o count_. Apesar disso estar correto, não é simples assim, não esqueça que todos os nós apontados pelo rootNode_ são dados controlados pela classe, que também precisam ser sincronizados.

Olhando o fonte dessa classe, todos os métodos manipulam ou lêem essas duas variáveis. A forma mais fácil e óbvia seria cercar com um critical section o corpo de todas as funções da classe.

Em Win32, um critical section é definido pelo objeto (surpresa!) CRITICAL_SECTION. Esse objeto deve ser inicializado e terminado, dessa forma:

CRITICAL_SECTION cs;

//
// adivinha?
//
InitializeCriticalSection(&cs);

//
// aqui entramos no critical section. Quando uma thread está "dentro" de
// um critical section, se alguma outra thread tentar entrar ficará
// travada dentro da funcão EnterCriticalSection até que a primeira
// thread chame LeaveCriticalSection. Isso garante que somente uma thread
// executará esse trecho de código em um dado momento.
//
EnterCriticalSection(&cs);

//
// Saímos do critical section. Isso faz com que a próxima thread que estiver
// esperando no ponto do EnterCriticalSection seja liberada. Note que somente
// uma thread é liberada por vez. Caso mais de uma thread esteja esperando, elas
// são liberadas na ordem que chegaram "na portinha" do critical section
//
LeaveCriticalSection(&cs);

//
// análogo ao CloseHandle
//
DeleteCriticalSection(&cs);

Resumindo: o Critical Section cria um "gargalo", onde só passa uma thread de cada vez. Ah, existe uma coisa interessante a ser acrescentada à explicação do post sobre threads: as threads permitem que um processo execute várias linhas de execução ao mesmo tempo, mas essas linhas de execução podem rodar o mesmo código, que está no mesmo lugar na memória. Ou seja, elas compartilham dados e código executável.

No próximo post iremos para o exemplo prático.

8 comentário(s)

jumpi

2009-01-14T15:50:50+00:00

Continuing the posts about data types and your characteristics, I read a nice article about Floating point numbers published by gamasutra:

http://www.gamasutra.com/view/feature/1965/visualizing_floats

See ya!!!

jumpi

2009-01-06T03:45:04+00:00

Lendo uma thread em uma lista de discussão que acompanho, surgiu uma duvida bem interessante sobre NaN e em uma das mensagens me deparei com a seguinte afirmação.

“Números imaginários são um exemplo, sqrt (-1) retorna NaN. Outro é dividir zero ou +/- infinito por zero.”

Vamos analisar essa frase começando pelo fim.

De acordo com a IEEE 754, se eu tenho uma variável a = 0 e divido a mesma por 0, vai dar um NaN, porem se eu tenho em a um valor positivo que tende ao infinito, o valor vai ser positivo e se o valor de a for negativo, logo essa divisão vai resultar em um valor negativo.

Ok, até aqui nenhuma objeção, tudo nos conformes. Porém, porém… agora vamos a primeira afirmação.

“Números imaginários são um exemplo, sqrt (-1) retorna NaN.”

Ooopss…. Sinto que houve um equivoco ai, pois não foi definido pelo autor da frase em qual conjunto numérico ele está trabalhando, penso que ele se limitou a qualquer conjunto no qual sqrt(-1) realmente não tem solução (Q, R, Z…), porém, existe também o conjunto dos complexos e nesse conjunto, existe solução para sqrt(-1). E vamos provar isso utilizando o nosso velho amigo C++, pois ele possui uma classe/template por padrão que trabalha com números complexos usando tipos de ponto flutuante, ou seja, utilizando o nosso amigo, podemos provar que existe sim solução para sqrt(-1) no campo dos complexos

Listarei logo abaixo um código simples que demonstra a nossa teoria em C++, ou seja, provar que existe sim resposta para sqrt(-1) e que ela é diferente de NaN

(jumpi@Painkiller:~)$ vi complex.cpp


#include <iostream>
#include <complex>

using namespace std;

int main(int argc, char **argv)
{
    complex<float> res = sqrt(complex<float>(-1));
    cout << res << endl;
    return(0);
}

(jumpi@Painkiller:~)$ ./complex
(0,1)
(jumpi@Painkiller:~)$

Antes recapitulando, a forma geral de um numero complexo no seu plano obedece a forma a + b*i, onde a representa o numero real e b um numero imaginário, ou seja, o retorno do tipo complex em C++ retorna as coordenadas de um numero complexo no plano.

No nosso caso, substituindo na fórmula, teremos a + b*i == 0 + 1*i que equivale a i.

Vamos fazer o teste para confirmar?? Utilizando o google, sim… o google, pois a busca serve como uma excelente calculadora e vai nos ajudar com a prova, digite sqrt(-1), qual a resposta??? Sim… sim… sqrt(-1) equivale a i, mesmo resultado apresentado pelo nosso simples programinha em C++.

Q.E.D.

Logo, sqrt(-1) = i e não um NaN conforme foi dito na thread.

Essa foi apenas uma demonstração de que não podemos esquecer da base matemática para formular uma resposta, principalmente no que envolve recursos que podem ser representados pela linguagem.

Maiores informações podem ser encontradas nos seguintes sites:

Wolfram Complex Number
Wolfram Complex Plane
C plus plus complex reference

C++: Quando usar cada Smart Pointer

2008-12-24T18:42:48+00:00

auto_ptr, shared_ptr, scoped_ptr, … Qual utilizar ? E, principalmente, por quê ? Primeiramente, vamos recordar o que é um Smart Pointer e quais são os recursos que geralmente utilizamos dele. Após isto, ficará mais fácil identificar qual deles usar. Um Smart Pointer (SP) é uma classe template que guarda um ponteiro para um objeto que é dinamicamente alocado ou, sendo mais explícito, alocado

Básico do básico: tipos

2008-12-12T17:26:01+00:00

Um tipo nada mais é que do que uma forma (ô) de bolo, que molda a memória como acharmos melhor moldá-la. Bom, para isso fazer sentido é necessário explicar memória, que é um conceito mais básico ainda.

A memória é qualquer lugar onde eu possa guardar alguma coisa. No artigo anterior era um punhado de gavetas. Mas poderiam muito bem ser caixas de presente. Ou um caderno. Ou até uma placa de memória RAM. O que sua criatividade quiser.

O importante no conceito de memória, computacionalmente falando, é saber que ela pode guardar qualquer tipo de informação, mas ela não sabe o que você está guardando. E eis que surge o segredo do tipo: ele conta para você, e seu programa, o que de fato está guardado na memória.

Vamos exemplificar.

Este artigo é um punhado de números na memória

Computadores trabalham muito bem com números. A própria memória só guarda valores numéricos. Porém, se é dessa forma, como conseguimos abrir o Bloco de Notas e digitar algum texto?

Para entender essa "mágica" é necessário vir à tona o conceito de representação, um tema que ainda pode dar muito pano pra manga quando estudarmos base numérica. Por enquanto, basta saber que uma representação é um faz-de-conta em que todos concordam com o que for dito. Por exemplo: Faz de conta que a letra 'A' é o número 65. Dessa forma, sempre que for visto o número 65, de agora em diante, será vista a letra 'A' no lugar.

Existem alguns faz-de-conta que são muito difundidos entre e humanidade informática. Um deles é chamado tabela ASCII (se pronuncia "ásqui"). É uma forma de todos conseguirem entender os textos de todo mundo. Abaixo podemos ver a representação de todas as letras maiúsculas na codificação ASCII:

Número  Letra
======  =====
65      A
66      B
67      C
68      D
69      E
70      F
71      G
72      H
73      I
74      J
75      K
76      L
77      M
78      N
79      O
80      P
81      Q
82      R
83      S
84      T
85      U
86      V
87      W
88      X
89      Y
90      Z

Agora, imagine que você digitou o seguinte texto no bloco de notas:

CASA

Como esse texto é guardado na memória de um computador, se ele só entende números?

Através da nossa já conhecida tabela ASCII! Na verdade, números são armazenados na memória, mas por representarem as letras 'C', 'A', 'S' e 'A', são traduzidos de volta para o formato texto pelo Bloco de Notas, que conhece o que guardou na memória.

A memória pode guardar qualquer coisa com números

A técnica de representação pode guardar qualquer coisa na memória como números que serão traduzidos por algum programa que consiga abrir aqueles dados. Dessa forma podemos não só armazenar texto, como imagens, vídeos, páginas web e até mesmo os próprios programas que os abrem!

Na programação do dia-a-dia, as coisas funcionam da mesma forma. As tão faladas variáveis reservam um espaço de memória para guardar alguma coisa, mas só sabemos o que essa alguma coisa é através do tipo da variável:

// a variável idade (espaço de memória)
// pode guardar um número (tipo)
int idade; 

// a variável nome (espaço de memória) pode
// guardar o nome de alguém de até 99 letras (tipo)
char nome[100]; 

// a variável cad (espaço de memória) pode
// guardar o cadastro de uma pessoa (tipo)
Cadastro cad;

Esses elementos, na memória, são um bando de número que, sem os tipos, não possuem significado algum, como podemos ver na depuração do programa abaixo:

Note que os números não estão aqui representados em decimal, onde se esperaria 35 e 42, pois a representação formal da memória geralmente está no formato hexadecimal, transformando esses números em 0x23 e 0x2a, respectivamente. Para entender essa diferença cabe estudar um pouco sobre base numérica, outro tema básico do programador sólido.

Practice makes perfect

Nada é bem aprendido se não for apreendido. Algumas tarefas programáticas que podem fixar o conceito de tipo estão listadas abaixo:

Usar printf especificando tipos diversos (%d, %s, %f, %p, ...) para a mesma variável, inclusive correndo o risco de gerar algumas exceções.
Usar scanf especificando diversas variáveis para o mesmo tipo (%d, %s, %f, %p, ...), vendo o resultado da leitura da entrada do usuário na memória.
Tentar copiar o conteúdo de uma variável para outra variável de tipo diferente. Sempre analise a memória para ver o resultado.

Outros faz-de-conta bem famosos

Ordenação de extremidades: O problema Little Endian e Big Endian.
UNICODE: Por um conjunto de letras universal.
Base numérica: O que são binário e hexadecimal e como eles afetam nossa vida.

Por onde andas skhaz?

2008-12-10T14:45:19+00:00

Depois de um bom tempo sem postar, devido há inumeras coisas, como mudança de emprego, escolher um toolkit para criação de ‘GUI’s e aprende-lo, o fim de um namoro de 3 anos, e muita correria… enfim o bom filho a casa retorna.

A boa noticia é que aprendi muitas coisas novas (sem maldade xD) como as bibliotecas Qt, phonon, Webkit, e aprendi mais sobre as que eu já sabia (boost e stl), expressões regulares e até uma linguagem nova chamada Ruby

Eu sempre achei a idea de usar combobox, checkbox, etc como filtro uma idea complicada, ter que ficar marcando e depois clicar em filtrar, entao pensei em algo assim, basta voce digitar qualquer atributo do material que já vinha tudo que for relevante, por exemplo “AL TR”, já retorna todos os alumunios que são trifilados. No video da para se ter uma idea do que eu escrevi (claro que não é nenhum google, é bem simples)

E aqui o codigo responsável pela busca

void ItemView::filterChanged(const QString& text)
{
	QString filter, query;
	QStringList list = text.split(" ", QString::SkipEmptyParts);
 
	for (int i = 0; i < list.size(); ++i) {
		filter.append(QString(" %1 nome ILIKE '\%%2\%'").arg(
			list.size() > 1 && i != 0 ? " AND " : " ").arg(list.at(i)));
	}
 
	model->setFilter(filter);
}

Onde model é um ponteiro do tipo QSqlTableModel, e o metodo setFilter nada mais é do que a inserção da clausa WHERE

Se voce quer aprender mais como a Qt implementa o padrão de projeto Model-View-Controller leia aqui

É isso ae, espero que gostem, qualquer duvida, critica e/ou sujestões já sabem

techberto

2008-12-06T13:19:23+00:00

Em 1996 eu fiquei extremamente feliz quando recebi minha edição da Dr.Dobbs e vi um artigo escrito por brasileiros chamado “Lua: an extensible embedded language”, confesso que fiquei tão surpreso que acabei comentando com vários colegas sobre o artigo e sobre esta linguagem que eu já tinha ouvido falar mas não conhecia ainda e acabei ficando com o estigma de ser o “cara do Lua” por alguns meses. Oito anos depois, ao encontrar um colega de faculdade ele veio me perguntar se eu “ainda” programava em Lua.

Após 11 anos, tive outra boa surpresa quando conheci o projeto eLua, que é mantido pelo romeno Bogdan Marinescu em conjunto com o brasileiro Dado Sutter do laboratório LED da PUC-Rio, que basicamente é um projeto que insere Lua no contexto de programação de microcontroladores, oferecendo melhor reusabilidade de código e redução de complexidade e custo de desenvolvimento.

Hoje ele tem suporte para as plataformas LM3S, AT91SAM, STR9, STR7, LPC2888, i386 e segundo o Dado Sutter logo o eLua estará suportando novas MCUs, assim como mais exemplos tem sido escritos com boa frequencia e novos módulos estão em desenvolvimento. Eu o testei no meu AT91SAM7×256 e fiquei muito entusiasmado com o projeto.

Para quem ficou interessado em saber um pouco mais sobre o e-Lua, o projeto está com um novo site – baseado no Sputnik que é um Wiki engine 100% escrito em Lua – e a URL oficial do projeto é www.eluaproject.net

Básico do básico: ponteiros

2008-12-06T04:42:22+00:00

Nessas últimas semanas tenho gastado meu tempo junto da mais nova pupila da SCUA, aspirante a programadora em C e Install Shield Script. Minha tarefa? Explicar tudo, desde o mais simples, como variáveis, até as coisas não tão triviais, como símbolos de depuração.

Posso afirmar que tem sido muito compensador ativar algumas partes do meu cérebro que acreditava nem mais existirem. Rever velhos conceitos, apesar de manjados, nos dá a oportunidade de lembrar que as coisas mais complexas que construímos no dia-a-dia se baseiam em um punhado de preceitos básicos que é essencial ter na cabeça. E nunca esquecê-los.

Meu amigo costuma chamar esses preceitos básicos de fundamentais. Isso por um bom motivo lógico e semântico: tudo que aprendemos de básico sobre qualquer área de conhecimento serve-nos de base para suportar as outras coisas que virão a ser entendidas na mesma área de conhecimento. Ou seja: é a parte mais importante a ser aprendida. Sem ela, a base, não nos é possível construir nada sólido e duradouro. Sem ela, toda a estrutura construída a posteriori se rompe e vai abaixo.

Foi partindo desse princípio que me preocupei com esmero para explicar as peças mais fundamentais do conhecimento em jogo, formadoras da cabeça de um programador para sempre, seja em C como em qualquer outra linguagem. E como nada é bem explicado sem formar imagens na cabeça, aproveitei para desenhar alguns esboços no papel. Aqui vão algumas explicações que estive artisticamente "documentando" para minha nova colega.

Ponteiro: o eterno vilão da história

Não tenho a presunção de conseguir explicar 100% para alguém iniciante o que são ponteiros em C, como usá-los e como se proteger deles. Definitivamente ponteiro não é um conceito simples, apesar de básico, e posso dizer sem vergonha que demorei cerca de seis meses no meu aprendizado em C pra entender completamente tudo relacionado com ponteiros. Demorou, quebrei a cabeça, mas depois nunca mais esqueci.

De acordo com o meu amigo Rafael, a melhor definição que usei até hoje para explicar esse conceito envolvia um armário repleto de gavetas, todas numeradas em ordem de posição (1, 2, 3...). Cada gaveta podia guardar qualquer coisa, inclusive o número de outra gaveta em um pedaço de papel. Com isso, eu poderia guardar em uma gaveta aleatória o que eu precisava guardar e escrever o "endereço" dessa gaveta em um pedaço de papel e guardá-lo na gaveta número 1, por exemplo. Com isso poderia até esquecer a posição onde está o que eu guardei, pois bastava abrir a gaveta número 1 e ler a posição em que estava essa gaveta.

Deve ter ficado óbvio, mas se não ficou: o armário é a memória RAM, as gavetas são váriáveis e as gavetas onde guardamos pedaços de papel são ponteiros, que não deixam de ser variáveis, e apontam para outras gavetas que são... adivinha? Outras variáveis!

Outros conceitos que costumo utilizar é relacionar a memória RAM com a memória do programa e contar a memória como se contam carneirinhos. Dessa forma fica fácil pelo menos entender dois conceitos fundamentais na arte dos ponteiros: memória e endereço.

Practice makes perfect

O segundo passo, acredito eu, é entender como a memória é dimensionada através do programa, e como o tipo molda a representação dos bits e bytes através das ligações de silício, mas isso fica pra mais tarde. Temos que programar, e é isso que vai de fato fazer a diferença no aprendizado de uma linguagem como C. Nada como uma boa mistura de teoria e prática para gerar um concreto armado que irá suportar um Empire State de conhecimento.

Por isso, segue uma lista de tarefas interessantes para exercitar o conceito de ponteiros:

Criar funções que modificam números passados como parâmetro.
Criar funções que modificam texto passado como parâmetro.
Alocar e desalocar memória dinamicamente.

Tarefas mais específicas da minha área e que uso o tempo todo:

Escrever e ler texto em arquivos.
Escrever e ler no registro do Windows.
Obter o endereço de uma função do Windows dinamicamente. E chamá-la.

Nota: Não use as classes superiores de C++ nem referências. Estou falando de estudar ponteiros nua e cruamente. Não seja preguiçoso. Algumas coisas devem ser feitas da maneira mais "primitiva" até se entender com o que se está lidando. Lembre-se que os melhores programadores possuem os alicerces mais fortes.

techberto

2008-12-04T16:29:06+00:00

Talvez um teco influenciado pelo documento “Prospectiva Estratégica, Metodologia de Descrição de Cenários” temperada a puro palpite visionário, outro dia quando na piclistbr o Mak lançou esta:

1996 – um supercomputador usava 10 mil processadores Pentium Pro clocados a
200 MHz pra atingir 1 teraflops (um trilhão de operações matemáticas por
segundo). ocupava um andar inteiro de um laboratório no Novo México. Ele
consumia absurdos 500 kW e, pasme, mais 500 kW só de cooler, ar-condicionado
e tudo o mais para manter a sala geladinha e não pifar a bagaça.

2008 – uma Radeon HD 4870, placa de video das mais rápidas atualmente,
atinge esse mesmo número de flops com apenas um chip. A placa de vídeo da
AMD, assim como as outras dessa categoria, cabe num slotzinho PCI Express e
gasta 110 watts, o que já é uma cavalice.

2015 – tentem fazer uma projeção…

Fonte: PAPO DE MICREIRO: O lado hardcore da tecnologia, Placa de vídeo ou arma de detonação em massa? por Marco Aurélio Zanni

E lancei o seguinte cenário:

2050: Life, the Universe and Everything: q-bits e processamento de
chuckflops por segundo serão triviais. Seth Lloyd e Miguel Nicolelis
serão mais populares que Von Newman e Alan Turing. Haverá dispositivos
computacionais com processamento de chuckflops do tamanho de um
alfinente usados como implantes com baterias recarregáveis via
wireless. Todo boteco terá um recarregador wireless. Estes implantes
computacionais usarão o protocolo 802.11xyz para se conectar com a
spacenet, seja da Terra ou de Marte e a segunda língua mundial será o
chinês. Via 802.11xyz q-telepatia será algo muito comum; porém isto
será coisas para os jovens, a galerinha de 80 e 90 anos ainda usará
menssegers baseado nos protocolos XMPP em seus handhelds.

A plebe ainda usará estes dispositivos de 2015, com PCs digitais com
placas de vídeo com meros 100 teraflops consumindo os exagerados 70
Watts, utilizando toda a arcaica tecnologia digital binária. Ainda
existirão analfabetos digitais e ONGs lutando contra a fome mundial,
isto em 2050.

2100: Em 2100 os Estados Unidos elegerá o primeiro presidente
marciano, descendente de terráqueos chineses e brasileiros, que foram
para a colônia marciana em 2060, que se promoveu a base de q-telepatia.

(…)

OK: Para justificar este minha prospecção eu teria que escrever um relatório de mais de 100 páginas, mas está aí um cenário factível, não exatamente nestas datas e com esta terminologia, mas num futuro não muito distante.

Vídeo-Palestra: Unit Testing

2008-11-25T23:04:55+00:00

Ótimo vídeo sobre escrita de código limpo e testável, do Google Tech Talks. Se você ainda não percebeu ou não está convencido de que o uso de TDD vale à pena, não deixe de assistí-lo. FICHA DO VÍDEOPalestra : Unit TestingPalestrante : Misko Hevery, Agile Coach do GoogleEvento : The Clean Code Talks, do Google Tech TalksData : 30 de outubro de 2008Idioma : Inglês

Watching directory AND Application Restart/Recovery

2008-11-18T15:23:10+00:00

This is a sample using Visual C++ and Windows API that works with Windows Vista or later.

The main purpose is to show how to use Standard C++ Library TR1 Extensions Reference, directory change notification and application restart/recovery (ARR) in native code.

#include <windows.h>
#include <process.h>
#include <iostream>
#include <functional>

using namespace std;
using namespace std::tr1;

#ifdef _UNICODE
#define _tcout wcout
#define _tstring wstring
#else
#define _tcout cout
#define _tstring string
#endif

class DirectoryWatcher
{
public:
typedef std::tr1::function<void (LPCTSTR)> NotifyChangeHandler;

DirectoryWatcher( const wstring& dir, NotifyChangeHandler changeCallback ) :

Dir_(dir), Started_(false), ChangeCallback_(changeCallback)
{
}

void Start()
{
if( !Started_ )
{
    Started_ = true;
    unsigned int threadId;
    HANDLE threadHandle = reinterpret_cast<HANDLE>(_beginthreadex( NULL, 0, WatchDirectory, this, NULL, &threadId ));
    CloseHandle(threadHandle);
  }
}

private:
static unsigned int WINAPI WatchDirectory( LPVOID pArguments )
{
    DirectoryWatcher* w = reinterpret_cast<DirectoryWatcher*>(pArguments);
    w->_WatchDirectory();
    return 0;
}

void _WatchDirectory()
{
    LPCTSTR dir = Dir_.c_str();
    HANDLE handleToWatch = FindFirstChangeNotification( dir, FALSE, FILE_NOTIFY_CHANGE_FILE_NAME );
    if ( INVALID_HANDLE_VALUE == handleToWatch )
         ExitProcess(GetLastError());

    while (TRUE)
    {
        if( WAIT_OBJECT_0 == WaitForSingleObject( handleToWatch, INFINITE ) )
        {
            ChangeCallback_( dir );
            if ( !FindNextChangeNotification( handleToWatch ) )
                ExitProcess(GetLastError());
        }
        else
        {
            ExitProcess(GetLastError());
        }
    }
}

private:
DirectoryWatcher(){}
DirectoryWatcher( const DirectoryWatcher& ){}
DirectoryWatcher& operator=( const DirectoryWatcher& ){}

const wstring Dir_;
bool Started_;

NotifyChangeHandler ChangeCallback_;
};

void OnDirectoryChange( LPCTSTR lpDir )
{
_tcout << TEXT("Refresh the directory ") << lpDir << endl;
}

typedef std::tr1::function<void (void)> DoRecoveryHandler;

DWORD WINAPI PrepareToRecover( PVOID pArgument )
{
BOOL bCanceled = FALSE;
_tcout << TEXT("Preparing recovery...\n");
ApplicationRecoveryInProgress( &bCanceled );
if (!bCanceled)
{
    if( pArgument )
    {
      DoRecoveryHandler* recoveryFun = reinterpret_cast<DoRecoveryHandler*>(pArgument);
      (*recoveryFun)();
    }
}
else
{
    _tcout << TEXT("Recovery was canceled by the user.\n");
}

_tcout << TEXT("Recovery completed...\n");
ApplicationRecoveryFinished((bCanceled) ? FALSE: TRUE);

return 0;
}

void RecoverFromRestart()
{
_tcout << TEXT("Perform recovery from restart...\n");
}

bool IsApplicationRestarting( const _tstring& cmdLine, LPCWSTR restartFlag )
{
return _tstring::npos != cmdLine.find( restartFlag );
}

void OnDoCustomRecover()
{
_tcout << TEXT("Custom recovery procedure...\n");
}

int main()
{
_tstring cmdLine( GetCommandLine() );
LPCWSTR restartFlag = TEXT("/restart");
bool isAppRestarting = IsApplicationRestarting( cmdLine, restartFlag );
_tcout << TEXT("Command Line = ") << cmdLine.c_str() << TEXT("\n");

if( isAppRestarting ) RecoverFromRestart();
HRESULT hr = RegisterApplicationRestart( restartFlag, 0 );
  if( FAILED( hr ) )
  {
    _tcout << TEXT("Restart registration failed\n");
    return 1;
}

DoRecoveryHandler customRecovery( OnDoCustomRecover );
hr = RegisterApplicationRecoveryCallback( PrepareToRecover, &customRecovery, RECOVERY_DEFAULT_PING_INTERVAL, 0 );
if( FAILED( hr ) )
{
    _tcout << TEXT("Recovery registration failed\n");
    return 2;
}

DirectoryWatcher dw( TEXT("D:\\Test\\"), OnDirectoryChange );
dw.Start();
if( !isAppRestarting )
{
    //force restarting...
    Sleep(60 * 1000 + 1 * 1000);
    RaiseException( EXCEPTION_ILLEGAL_INSTRUCTION, EXCEPTION_NONCONTINUABLE_EXCEPTION, NULL, NULL );
}
else
{
//continue...
Sleep( 60 * 60 * 1000 );
}
}

According to ARR documentation: "To prevent cyclical restarts, the system will only restart the application if it has been running for a minimum of 60 seconds."

Evento: CodeRage 2008 (online)

2008-11-15T08:20:00+00:00

De 1 à 5 de dezembro rola o 3º CodeRage, evento online promovido pela Embarcadero, que apresenta diversas palestras em sessões onde é possível trocar informações com outros desenvolvedores, analisar ferramentas de desenvolvimento e muitas outras coisas. São mais de 80 sessões, com algumas palestras em Português do Brasil. Dentro alguns assuntos abordados estão (vou listar em inglês, que é como

Ferramentas de apoio Win32: pskill

2008-10-31T16:55:51+00:00

O pskill é mais um ferramenta Sysinternals sem a qual a vida fica muito difícil. A única coisa que ele faz - e bem feito - é matar um processo. Parece simples, mas quando você precisa matar 7 processos toda vez que seu servidor dá pau, uma bat cheia de chamadas ao pskill pode salvar a sua vida.

Alguns usos:

Ela aceita tanto o nome do processo quanto o PID: você pode chamar pskill notepad.exe ou pskill 4576.
Quando você usa o nome, ele mata TODOS os processos com o mesmo nome: Ou seja, um pskill notepad.exe vai matar TODAS as instância do notepad. Se você quer matar uma instância específica, use o PID. Se precisar saber o PID do processo em command line, use o pslist, ferramenta que veremos em mais detalhes depois.
Matar um processo e todos criados por ele: pskill -t meu-servico.exe. Mata o processo pai e toda sua família.
Funciona remotamente: você pode chamar pskill \\outra-maquina notepad.exe ou pskill \\outra-maquina 4576. Como sempre, você precisa ter permissão para isso na máquina remota

Informação muito importante: pskill \\maquina-remota winlogon.exe causa um BugCheck (tela azul) instantâneamente na máquina remota. Use com moderação.

4 comentário(s)

Delphi Generics: Diferenças entre compiladores

2008-10-30T04:57:05+00:00

Tanto o Free Pascal Compiler (FPC) quanto o CodeGear Delphi possuem suporte a generics, as extensões que permitem definir quais tipos de dados serão usados por classes ou funções (por exemplo) no momento de sua declaração. Hoje há uma tendência da adoção de generics em praticamente todas as linguagens OO. C++ tem seus templates desde o ISO C++94, Java adotou generics a partir de sua versão J2SE

C++: Multi-dimensional analog literals

2008-10-30T02:48:19+00:00

Interessante as coisas que podemos fazer com C++ padrão.Veja um exemplo de uma biblioteca construída com templates para simular a construção de objetos multi-dimensionais através de seu formato. Criar linhas, retângulos e cubos assim fica até mais divertido. ;)Multi-Dimensional Analog Literals

Evento: C e C++ para Sistemas Embarcados

2008-10-28T13:42:15+00:00

Acontece em São Paulo no dia 8 de novembro, sábado, um evento sobre Sistemas Embarcados, onde serão abordados algumas temas interessantes, como: Técnicas de Programação em C para Sistemas EmbarcadosUtilização de C++ em MicrocontroladoresExplorando os 16 bits da Microchip e as ferramentas de trabalhoOtimização de código C para sistemas embarcadosDesenvolvimento Embedded no Mundo da eLuaAs

TDD na Prática - Parte II: Verificação e Confiabilidade

2008-09-27T16:28:20+00:00

Como visto na Parte I, para criar código (que seja facilmente) "testável" é preferível escrever código que o testa primeiro. Exercitar o código verificando seus limites e estados auxilia na descoberta de como o mesmo deve se comportar e traz um maior controle sobre seu funcionamento. Conseqüentemente, culmina em um maior nível de confiabilidade. Tornar freqüente a verificação do código, de

V

2008-09-23T03:12:21+00:00

Parabéns a todos que participaram e ajudaram para que todos nós chegássemos ao quinto encontro de programadores/aficionados C/C++. Parece mentira, mas hoje temos capacidade para lotar um auditório razoável, e temos a ousadia de sempre poder contar com uma grade de palestras pra lá de avançadas. Vejamos o que foi visto até hoje nesses últimos três encontros (III, IV e o seminário):

C++ com WxWidgets
O novo padrão C++0x
Threads no C++ ISO
C e microcontroladores
Drivers para Windows
TCP/IP via Boost.Asio
C++ com Qt
Dicas de portabilidade
Programação concorrente
C++ com STL/Boost
Otimização de código

E esse é só o começo.

Grade para o Quinto Encontro CCPP

04 de outubro de 2008, São Paulo, Brasil

Ferramentas para programação C++ para Windows por Rodrigo Strauss
Programando com Conceitos no novo C++ por Leandro Melo
Arquivos de memória mapeada no Windows com C++ por Basílio Miranda
Explorando o Windows (Vista & Server 2008) com C++ por Fábio Galuppo
Criando Linguagens Embutidas para Otimização por Felipe Almeida

Grade para o Evento C & C++ Para Sistemas Embarcados

08 de novembro de 2008, São Paulo, Brasil

Técnicas de Programação em C para Sistemas Embarcados por Daniel Quadros
Utilização de C++ em Microcontroladores por Luiz Barros
Explorando os 16 bits da Microchip e as ferramentas de trabalho por Daniel Rodrigues
Otimização de código C para sistemas embarcados por Fábio Pereira
Desenvolvimento Embedded no Mundo da eLua por Dado Sutter

Se repararam, o número de palestras foi acrescido de um (palestras++) e o tempo para cada uma delas foi ligeiramente encolhido. Espero que esse não seja um empecilho para o desenvolver dos assuntos, pois existem alguns bem delicados acima (como a linguagem embutida e memória mapeada) para serem explicados em cerca de uma hora.

É isso aí. Vida longa ao C++! (e ao C! e ao COBOL! e ao FORTRAN!)

Vídeo-Palestra: Modelagem Ágil

2008-09-16T23:22:13+00:00

Palestra sobre Modelagem Ágil em português. Palestrante: Manoel Pimentel Evento: TDC 2008

TDD na Prática - Parte III: Abstração, Simplificação e o Ciclo do TDD

2008-09-06T19:36:54+00:00

Conhecer como verificar as partes do software e estabelecer o nível de abstração para obter os dados a serem verificados é um ponto vital quando se escreve código de teste. Expor uma interface simples em uma classe e esconder seus detalhes de implementação é imprescindível para alcançar um modelo de fácil reutilização, substituição e que possa ser facilmente testado. Dependências entre

TDD na Prática - Parte 1: Influência no Design

2008-09-06T17:27:03+00:00

Para se ter uma idéia rápida de como é TDD na prática, criarei um joguinho bem simples, e de conhecimento geral, que deve servir como exemplo: o Jogo da Velha. (Se você não teve infância ou sofre de perda grave de memória, consulte as regras aqui. :) Para verificar se a implementação do jogo estará correta, escreverei código que a teste. Mas daí vem algumas questões: Como terei certeza de

Vídeo-Palestra: Extreme Programming

2008-08-24T19:08:07+00:00

Palestra recomendada para quem quer conhecer melhor como é o desenvolvimento ágil utilizando Extreme Programming. Em português (!). Palestrante: Vinícius Manhães Teles, da ImproveIt Evento: TDC 2008

Interação e Substituição de Objetos

2008-08-21T10:24:24+00:00

Ter uma visão clara de como os objetos interagem é um fator fundamental no desenvolvimento de software orientado a objetos. É até mais importante do que saber como cada objeto funciona isoladamente. Pensando que um software O. O. é uma espécie de teia de objetos que se interconectam, fazendo de sua interação o fator gerador do comportamento do software, mudar seu comportamento será como plugar

O que virá

2008-08-19T22:27:24+00:00

Uma idéia do que deve ser visto por aqui: Metodologias e Processos Muita gente ainda desconhece ou tem uma visão um tanto turva sobre Metodologias Ágeis, Scrum, XP, TDD, etc. e de diversos outros assuntos relacionados a metodologias de desenvolvimento de software. Espero deixar aqui minha contribuição para esclarecer alguns pontos, com enfoque prático, fazendo um balanço sempre pragmático.

Blog::Start()

2008-08-13T01:04:01+00:00

{ if ( YouLikeSoftwareDevelopment() ) ThatsTheRightPlace(); else GoToMyAnotherSite(); // www.thiagodp.blogspot.com }

Reflexão em C++

2008-06-30T04:02:38+00:00

O termo e conceito de "reflection" (reflexão), muito usado em linguagens modernas, é a capacidade de um programa de observar e até de alterar sua própria estrutura. Bom, isso você pode ler na Wikipédia. O interessante é o que podemos usar desse conceito na linguagem C++.

Infelizmente não muito.

O sistema de RTTI (Run Time Type Identification), a identificação de tipos em tempo de execução, seria o começo do reflection em C++. Foi um começo que não teve meio nem fim, mas existe na linguagem. Dessa forma podemos tirar algum proveito disso.

Um leitor pediu para que eu falasse um pouco sobre essas coisas, especificamente como se faz para obter o nome da classe de onde estamos executando um determinado método. Para esse tipo de construção podemos usar o operado typeid, que retorna informações básicas sobre um tipo de acordo com um tipo, instância ou expressão:

#include <iostream>
 
using namespace std;
 
int main()
{
	cout << typeid( int ).name() << endl;
 
	int x;
	cout << typeid( x ).name() << endl;
 
	cout << typeid( 2 + 2 ).name() << endl;
}

C:\Tests>cl typeid.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:typeid.exe
typeid.obj

C:\Tests>typeid.exe
int
int
int

Dessa forma, podemos nos aproveitar do fato que todo método não-estático possui a variável implícita this, do tipo "ponteiro constante para T", onde T é o tipo da classe que contém o método sendo chamado.

#include <iostream>
 
using namespace std;
 
class MyClass
{
	public:
		void MyMethod()
		{
			cout << typeid(*this).name() << "::MyMethod" << endl;
		}
};
 
int main()
{
	MyClass myc;
 
	myc.MyMethod();
}

C:\Tests>cl typeid-class.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:typeid-class.exe
typeid-class.obj

C:\Tests>typeid-class.exe
class MyClass::MyMethod

Com classes não-polimórficas a coisa parece não ter muita utilidade. No entanto, essa mesma técnica pode ser aplicada em classes derivadas, uma vez que o operador typeid pode trabalhar em tempo de execução:

#include <iostream>
 
using namespace std;
 
class MyClass
{
	public:
		virtual void MyMethod()
		{
			cout << typeid(*this).name() << "::MyMethod" << endl;
		}
};
 
class MyDerivatedClass1 : public MyClass { };
 
class MyDerivatedClass2 : public MyClass { };
 
int main()
{
	MyClass* myc1 = new MyDerivatedClass1;
	MyClass* myc2 = new MyDerivatedClass2;
 
	myc1->MyMethod();
	myc2->MyMethod();
}

C:\Tests>cl typeid-class2.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:typeid-class2.exe
typeid-class2.obj

C:\Tests>typeid-class2.exe
class MyDerivatedClass1::MyMethod
class MyDerivatedClass2::MyMethod

Apenas se lembre de ter de fato uma classe polimórfica (eu consegui isso tornando MyMethod uma função virtual). Do contrário você pode ter problemas.

Two versions for Lock-Free Stack

2008-06-24T11:01:30+00:00

The two codes below are implementations of lock-free stack structure.

The purpose is the same, but the first version can be ported easily to other OSes.

Performance benchmark is a lesson to the reader.

The raw C++ implementation. In C++0x we'll change Interlocked APIs to atomic operations:

template

<typename T>
struct LockFreeStack
{
LockFreeStack() : Head_( NULL ){}

void Push( T& value )
{
    PNODE node = new NODE( value );
    PNODE oldHead;

    do
    {
      node->Next = oldHead = Head_;
    }while( oldHead != reinterpret_cast<PNODE>( InterlockedCompareExchangePointer(
                                      reinterpret_cast<volatile PVOID*>(&Head_), node, oldHead )));
}

T Pop()
{
    PNODE node;
    PNODE oldHead;

    do
    {
      oldHead = Head_;
    }while( oldHead != (node = reinterpret_cast<PNODE>( InterlockedCompareExchangePointer(
                                            reinterpret_cast<volatile PVOID*>(&Head_), Head_->Next, oldHead ))));

    T temp = node->Data;
    delete node;
    return temp;
}

private:
typedef struct NODE_TAG
{
    NODE_TAG( T value ) : Next(NULL), Data(value){}
    NODE_TAG* Next;
    T Data;
} NODE, *PNODE;

PNODE Head_;

LockFreeStack( const LockFreeStack& ){}
LockFreeStack& operator=( const LockFreeStack& ){}
};

Using a Windows API facility called Singly Linked Lists:

template<typename T>
struct LockFreeStack
{
LockFreeStack()
{
    Head_ = new_aligned<SLIST_HEADER>();
    if( NULL == Head_ )
      throw "memory allocation failed";

    InitializeSListHead( Head_ );
}

~LockFreeStack()
{
    InterlockedFlushSList( Head_ );
}

void Push( T value )
{
    Item_ = new_aligned<ITEM>();
    if( NULL == Item_ )
      throw "stack is full";

    Item_->Value = value;
    Entry_ = InterlockedPushEntrySList( Head_, &Item_->Entry );
}

T Pop()
{
    PSLIST_ENTRY tempEntry = InterlockedPopEntrySList( Head_ );
    if( NULL == tempEntry )
      throw "stack is empty";

    Item_ = reinterpret_cast<PITEM>( tempEntry );
    T temp = Item_->Value;
    _aligned_free( tempEntry );
    return temp;
}

private:
typedef struct ITEM_TAG
{
    SLIST_ENTRY Entry;
    T Value;
} ITEM, *PITEM;

PSLIST_ENTRY Entry_;
PSLIST_HEADER Head_;
PITEM Item_;

template <class M> M* new_aligned()
{
    return reinterpret_cast<M*>(_aligned_malloc( sizeof(M), MEMORY_ALLOCATION_ALIGNMENT ));
}

LockFreeStack( const LockFreeStack& ){}
LockFreeStack& operator=( const LockFreeStack& ){}
};

Samples from my Concurrency Talk at Seminário TempoReal C++ Portabilidade e Performance

2008-06-13T13:11:03+00:00

Samples from my Concurrency Talk at Seminário TempoReal C++ Portabilidade e Performance:

Concurrency C++ Samples
Concurrency C++ Slides (in brazilian portuguese)

The following code is a C++ port to one of my previous samples: MapReduce with Parallelspace

#include

<iostream>
#include <fstream>
#include <vector>
#include <map>
#include <string>
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/filesystem.hpp>
#include <boost/function.hpp>
#include <boost/algorithm/string.hpp>

using namespace std;
using namespace boost;
using namespace boost::filesystem;

void get_files( const path& directory, vector<path>& files )
{
directory_iterator end_iter;
for( directory_iterator iter( directory ); iter != end_iter; ++iter )
{
if( is_directory( iter->status() ) ) continue;
files.push_back( iter->path() );
}
}

int get_ProcessorCount(){ return 2; }

class TaskExecutor
{
typedef function2<void, map<string, int>&, const map<string, int>&> ConsolidationFunctionType;
typedef function1<map<string, int>, const path&> CountWordsFunctionType;

public:
TaskExecutor( vector<path>::const_iterator begin, vector<path>::const_iterator end,
                      const CountWordsFunctionType countWords,
                      const ConsolidationFunctionType consolidation,
                      map<string, int>& result ) : Begin_( begin ),
                      End_( end ),
                      CountWordsFunction_( countWords ),
                      ConsolidationFunction_( consolidation ),
                      Result_( result ){}

void operator()()
{
for( vector<path>::const_iterator iter = Begin_; iter != End_; ++iter )
ConsolidationFunction_( Result_, CountWordsFunction_( *iter ) );
}

private:
vector<path>::const_iterator Begin_, End_;
const ConsolidationFunctionType ConsolidationFunction_;
const CountWordsFunctionType CountWordsFunction_;
map<string, int>& Result_;
};

void key_count( map<string, int>& dictionary, const string& word, int value )
{
dictionary[ word ] = dictionary.end() != dictionary.find( word ) ? dictionary[ word ] + value : value;
}

map<string, int> map_function( const path& filename )
{
map<string, int> wordCount;

ifstream file;
const int MAXLEN = 1024;
char line[ MAXLEN ];

file.open( filename.directory_string().c_str() );

while( file.getline( line, MAXLEN ) )
{
    vector<string> split_v;
    split( split_v, string( line ), is_any_of( " " ) );
    for( vector<string>::const_iterator iter = split_v.begin(); iter != split_v.end(); ++iter )
      key_count( wordCount, *iter, 1 );
}

file.close();

return wordCount;
}

void reduce_function( map<string, int>& destination, const map<string, int>& source )
{
for( map<string, int>::const_iterator iter = source.begin(); iter != source.end(); ++iter )
key_count( destination, iter->first, iter->second );
}

void wordcount_mapreduced( const vector<path>& files, map<string, int>& wordCount )
{
//data partition
int numberOfPartitions = get_ProcessorCount() * 2; //2 threads per core
int numberOfFiles = static_cast<int>( files.size() );
if( numberOfFiles < numberOfPartitions ) numberOfPartitions = numberOfFiles;
int delta = numberOfFiles / numberOfPartitions;
vector< map<string, int> > result( numberOfPartitions );
thread_group tg;

//for parallel
for( int step = 0; step < numberOfPartitions; ++step )
{
    vector<path>::const_iterator begin = files.begin() + delta * step,
    end = numberOfPartitions - 1 == step ? files.end() : files.begin() + delta * step + delta;
    //fork
    tg.create_thread( TaskExecutor( begin, end, map_function, reduce_function, result[step] ) );
}

//join
tg.join_all();
for( vector< map<string, int> >::const_iterator iter = result.begin(); iter != result.end(); ++iter )
reduce_function( wordCount, *iter );
}

int main()
{
vector<path> files;
get_files( "c:\\txttest\\", files );
map<string, int> wordCount;

wordcount_mapreduced( files, wordCount );

for( map<string, int>::const_iterator iter = wordCount.begin(); iter != wordCount.end(); ++iter )
cout << iter->first << " = " << iter->second << endl;
}

Declaração x definição

2008-06-06T12:27:33+00:00

Uma diferença que eu considero crucial na linguagem C/C++ é a questão da declaração/definição (em inglês, declaration/definition). É a diferença entre esses dois conceitos que permite, por exemplo, que sejam criadas estruturas prontas para serem conectadas a listas ligadas:

struct Element
{
   int x;
   int y;
   Element* next; /* olha eu mesmo aqui! */
};

Por outro lado, e mais importante ainda, é ela que permite que as funções sejam organizadas em unidades de tradução (cpps) distintas para depois se unirem durante o link, mesmo que entre elas exista uma relação de dependência indissociável:

Existem diversas formas de entender esses dois conceitos. Eu prefiro explicar pela mesma experiência que temos quando descobrimos a divisão hardware/software:

Hardware é o que você chuta
Software é o que você xinga

Exatamente. Hardware é algo paupável, que você pode até chutar se quiser. Por exemplo, a sua memória RAM! No entanto, software é algo mais abstrato, que nós, seres humanos, não temos a capacidade de dar umas boas pauladas. Portanto, nos abstemos a somente xingar o maldito que fez o programa "buggento".

Da mesma forma, uma declaração em C/C++ nos permite moldar como será alguma coisa na memória, sem no entanto ocupar nem um mísero byte no seu programa:

int func(int x, int y, int z); /* tamanho em memória: zero bytes */

struct Teste
{
	char bufao[0x100000]; /* tamanho em memória: zero bytes */
	int intao[0xffffff];  /* tamanho em memória: zero bytes */
};

extern int x; /* tamanho em memória: adivinha! */

Por outro lado, a definição, o hardware da história, sempre ocupará alguma coisa na memória RAM, o que, de certa forma, permite que você chute uma variável (embora muitas outras também irão para o saco).

int func(int x, int y, int z) /* tamanho em memória:
{
	int ret = x + y + z; /* alguns _asm add + */
	return ret;          /* um _asm ret */
}

Teste tst; /* tamanho em memória: 0x100000 + 0xffffff * 4 = 1048576 bytes */

int x; /* tamanho em memória: sizeof(int) bytes */

Dessa comparação só existe uma pegadinha: uma definição também é uma declaração. Por exemplo, nos exemplos acima, além de definir func, tst e x, o código também informa ao compilador que existe uma função chamada func, que existe uma variável tst do tipo Teste e uma variável x do tipo int.

Informa ao compilador? Essa é uma outra ótima maneira de pensar a respeito de declarações: elas sempre estão conversando diretamente com o compilador. Por outro lado, nunca conversam diretamente com o hardware, pois ao executar seu código compilado, as declarações não mais existem. Foi apenas um interlúdio para que o compilador conseguisse alocar memória da maneira correta.

Complicado? Talvez seja, mesmo. Mas é algo que vale a pena fixar na mente. Isso, é claro, se você quiser ser um programador C/C++ mais esperto que os outros e resolver pequenos problemas de compilação que muitos perdem horas se perdendo.

Corolário

Então por que diabos a separação declaração/definição consegue definir coisas como listas ligadas, como no código acima? A resposta é um pouco ambígua, mas representa regra essencial na sintaxe da linguagem: após a definição do nome e do tipo de declaração envolvida podemos referenciá-la como declaração, ou seja, não ferindo a limitação de que não sabemos o tamanho de uma variável do tipo declarado. Dessa forma, é perfeitamente legal definirmos um ponteiro para uma estrutura que ainda não se sabe muita coisa, além de que é uma estrutura:

struct Estrutura; /* atenção: declaração apenas! */

Estrutura* st; /* ponteiro para declaração: não sabemos o tamanho ainda */

Dessa forma, o começo de uma definição de estrutura já declara o nome da estrutura antes de terminar a declaração do tipo inteiro. Bizarro, não? De qualquer forma, isso permite a construção clássica de lista ligada:

struct Estrutura /* a partir daqui Estrutura já está visível */
{
	Estrutura* st; /* recursividade? é apenas um ponteiro! */
};

Se vermos pelo lado prático, de qualquer forma seria impossível definir uma variável dentro dela mesma, pois isso geraria uma recursão infinita de definições, e, como sabemos, os recurso da máquina são finitos.

Resultado do Seminário CCPP

2008-06-03T00:17:05+00:00

Aconteceu nesse fim-de-semana, como era previsto, o nosso primeiro Seminário CCPP Brasil, com direito a pessoas de todas as idades e origens, mas todas com algo em comum: a paixão e o interesse pelas linguagens-mestre do mundo da programação.

Começo esse artigo agradecendo a todos os que direta e indiretamente participaram para o sucesso do evento, entre eles os organizadores, o carro-chefe responsável por acordar o espírito C++ da galera no início do ano, os palestrantes e, claro, óbvio, toda a comunidade C++ que participou em corpo (vulgo hardware) e alma (vulgo software).

Termino a introdução fazendo uma minicrítica ao preço pago pelos participantes. Não que eu ache que seja muito, pelo contrário: dado o alto nível técnico das palestras, parece até mentira termos acesso a um evento com essa estrutura por tão pouco. Porém, o muito e o pouco são relativos, e ainda acredito que existam pessoas que não vão aos encontros por falta de recursos. Por isso mesmo vai um apelo para que nos futuros encontros tenhamos alguma forma de permitir às pessoas menos favorecidas de participar democraticamente dessa que é a expressão viva das linguagens C e C++ em nosso país.

Vamos às palestras!

Dicas e Truques de Portabilidade
Wanderley Caloni

Apresentação para baixar em PDF, PPT e ODP.

É muito difícil analisar uma palestra feita por você mesmo. É mais difícil ainda quando essa palestra é a primeira de uma batelada de argumentações de alto nível técnico que seguiram o dia. Posso dizer, no entanto, que consegui o que queria quando fui para o evento: demonstrar as dificuldades e as facilidades de tornar um código portável, independente se entre sistemas operacionais, ambientes ou compiladores.

Foi visto primeiramente o que faz da portabilidade uma coisa difícil. Detalhes como sintaxe e gramática fazem toda a diferença quando o que se almeja é um código limpo de imperfeições trazidas pelo ambiente de desenvolvimento. Também foi dada especial atenção às famigeradas extensões de compiladores, que fazem a linguagem parecer uma coisa que não é.

Por fim, foram apresentadas algumas sugestões movidas pela experiência e estudo dessas mesmas dificuldades. Para ilustrar, dois exemplos bem vivos de como um código portável deve se comportar, tanto no código-fonte quanto em sua documentação.

Programação Concorrente com C++
Fábio Galuppo

Artigo sobre apresentação

Para quem está acostumado com os temas geralmente "gerenciados" de Fábio Galuppo com certeza deve ter se surpreendido com a descrição teórica dos inúmeros problemas que cercam a vida do programador multithreading. O palestrante partiu do mais simples, o conceito de threads, conceito que, segundo ele mesmo, pode ser explicado em 15 minutos, para algo mais sutil e que gera muitos erros escondidos: o conceito de locks (semáforos, mutexes, etc).

Os programadores em nível de sistema devem ter adorado o contexto histórico dos problemas (você sabia que o primeiro lock inventado foi o semáforo?) tanto quanto o contexto teórico (explicação sobre modelo de memória).

Um destaque especial foram os experimentos com código rodando de verdade no Visual Studio, como o exemplo que tenta criar o maior número de threads possível na arquitetura 64. Simplesmente assustador!

Se por um lado faltou tempo para explicar os usos e princípios das bibliotecas de programação paralela disponíveis e mais usadas do mercado, por outro a palestra preencheu uma lacuna importante na minha primeira palestra sobre threads em C++, demonstrando os erros mais comuns e o que não se deve fazer em programas que rodam mais de uma thread.

Mais uma vez voltando à teoria, a palestra foca mais uma vez em bons princípios de design, como o padrão de projeto monitor e a descrição dos modelos onde é justificado o uso de mais de uma thread no programa.

Programação Multiplataforma Usando STL e Boost
Rodrigo Strauss

Artigo sobre apresentação

Como sempre, Strauss está apaixonado pelo Boost (e a STL). Descrevendo as partes mais importantes que todo programador C++ moderno deve saber sobre essas bibliotecas, ambas modernas, a palestra focou principalmente no uso do dia-a-dia, e as vantagens produtivas que o C++ atual pode ter sobre o velho e tradicional programa em C com listas encadeadas artesanais.

Entre as coisas mais importantes citadas, que todo programador do novo século deveria saber, estão:

A total falta da necessidade de desalocarmos objetos manualmente em nossos programas, visto que o auto_ptr (STL) e shared_ptr (Boost) dão conta do recado de maneira impecável.
A total falta da necessidade de usarmos aqueles velhos arrays em C que quase nunca sabemos o tamanho exato para guardar nossos valores (e que continuamente colocávamos com o tamanho 100, MAX_PATH, ou UM_OUTRO_DEFINE_COMUM_EM_LINUX). A classe boost::array provê todas as funcionalidades básicas, além das avançadas, do uso de arrays tradicionais, sem qualquer overhead adicional de um array em C.
A total falta de necessidade de ficar convertendo strings e inteiros. Com a ajuda da classe std::string e de construções geniais como lexical_cast (Boost), felizmente podemos deixar nossas velhas funções que precisavam de um buffer, como _itoa (embora não-padrão).

Enfim, para quem pôde ver, a palestra focou nos princípios que farão hoje em dia um programador C++ completo, profissional e que, como seus colegas de outras linguagens, se preocupa igualmente com a produtividade de seu código. Ah, sim, e não gosta nem um pouco de reinventar a roda.
Técnicas de Otimização de Código
Rodrigo Kumpera & André Tupinambá

Aparentemente o que pensei que seria, em minha sincera opinião, um desastre (dois palestrantes falando sobre a mesma coisa) se transformou em uma combinação estupenda de teoria e prática aplicadas à arte de otimização de código. Rodrigo e André conseguiram destrinchar o tema harmoniosamente, sempre dividido entre técnicas avançadas (algumas demonstradas pela experiência dos palestrantes) e teoria disciplinar, que visa alertar o wannabe que otimizar pode ser uma coisa boa; porém, preste atenção aos que já fizeram isso têm a dizer.

Com uma didática impecável, o novato nesse tema (como eu) pôde ver as dificuldades de conseguir determinar o objetivo de todo otimizador de código que, segundo eles, deve estar sempre atento na máxima de que "toda otimização é na verdade uma troca". Ou seja, se o programador quer melhor processamento, pagará com memória, se quiser otimizar espaço na RAM, irá gastar mais com processamento e/ou disco, e assim por diante.

Foram apresentados exemplos reais de otimização, além de dicas muito importantes sobre o comportamento das compilaçõe de cada dia. Você sabia, por exemplo, que ao declarar em escopos mais locais suas variáveis usadas apenas em pequenos trechos de código, estará dando uma poderosa dica ao compilador para que ele consiga usar os registradores no máximo de sua capacidade?

Conclusão: estamos indo de bem a melhor!

Ao final, como é de praxe, tivemos um sorteio de ótimos livros sobre programação e C++ em geral, com destaque aos livros do Herb Sutter. Rodrigo Strauss, conhecido fundador dos encontros, recebeu sua mais que merecida homenagem ao receber um de seus livros autografados. É o mais novo MVP da comunidade!

E por falar em comunidade, e agora podemos ver claramente, estamos com uma força bem maior do que no início do ano. A seqüência de ótimos eventos, além de nossos mestres do conselho Jedi de programadores C++, prova finalmente que, se depender da qualidade dos desenvolvedores, o Brasil pode sim ser uma poderosa fonte de programas de qualidade que façam coisas bem mais interessantes do que acessar um banco SQL. Nós já temos a matéria-prima.

Mais linques sobre o evento

Discussão sobre o evento na nossa lista

Imagens do evento cedidas por Fernando Roberto (valeu, Ferdinando!).

Aquele do-while engraçado

2008-05-15T03:35:31+00:00

Nesses últimos dias andei conversando com um amigo que está estudando sistemas operacionais na faculdade. Melhor ainda, vendo o código real de um sistema operacional em funcionamento. A conseqüência é que, além de aprender um bocado de como as coisas funcionam de verdade debaixo dos panos, acaba-se aprendendo alguns truquezinhos básicos e tradicionais da linguagem C.

Por exemplo, é um hábito conhecido o uso de construções do-while quando existe a necessidade de definir uma macro que possui mais de um comando em vez de usar a igualmente conhecida { construção de múltiplos comandos entre chaves }.

O que talvez não seja tão conhecido é o porquê das coisas serem assim.

Vamos imaginar uma macro de logue que é habilitada em compilações debug, mas é mantida em silêncio em compilações release:

#ifdef NDEBUG
 
#define MYTRACE( message ) /* nothing */
 
#else
 
#define MYTRACE( message )        \
	{                              \
		char buffer[500];           \
		sprintf(buffer,             \
			"MYTRACE: %s(%d) %s\n",  \
			__FILE__,                \
			__LINE__,                \
			message);                \
		OutputDebugString(buffer);  \
	}
 
#endif /* NDEBUG */

Nada de mais, e parece até funcionar. Porém, como veremos nas próximas linhas, esse é realmente um exemplo de código "buguento", já que uma chamada dentro de uma construção if-else simplesmente não funciona.

if( exploded() )
	MYTRACE("Oh, my God");
else
	MYTRACE("That's right");

error C2181: illegal else without matching if

Por que isso? Para responder a essa questão nós precisamos olhar um pouco mais de perto no resultado do preprocessador da linguagem, que apenas troca nossa macro pelo pedaço de código que ela representa:

if( exploded() )
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"Oh, my God");
		OutputDebugString(buffer);
	};
else
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"That's right");
		OutputDebugString(buffer);
	};

Dessa forma, podemos ver o porquê. Quando chamamos a macro, geralmente usamos a sintaxe de chamada de função, colocando um sinal de ponto-e-vírgula logo após a chamada. Essa é a maneira correta de se chamar uma função, mas no caso de uma macro, dessa macro, é um desastre, porque ela cria dois comandos em vez de um só (um ponto-e-vírgula vazio, apesar de não fazer nada, é um comando válido). Então, isso é o que o compilador faz:

if( instruction )
{
	/* um monte de comandos */

} /* aqui eu esperaria um else ou uma instrução nova */

; /* uma instrução nova! ok, sem else desa vez */

else /* espere ae! o que esse else está fazendo aqui sem um if?!?! */
{
	/* mais comandos */
}

Pense sobre o comando vazio como se ele fosse um comando real, o que é a maneira mais fácil de entender o erro de compilação que recebemos ao compilar o código abaixo:

if( error() )
{
	printf("error");
}

printf("here we go");

else /* llegal else without matching if! */
{
	printf("okay");
}

Por essa razão, a maneira tradicional de escapar desse erro comum é usar uma construção válida que peça de fato um ponto-e-vírgula no final. Felizmente nós, programadores C/C++, temos essa construção, e ela é... muito bem, o do-while!

do
{
	/* múltiplos comandos aqui */
}
while( expression ) ; /* eu espero um ponto-e-vírgula aqui, para
                         finalizar minha instrução do-while */

Assim nós podemos reescrever nossa macro de logue da maneira certa (e todas as 549.797 macros já escritas em nossa vida de programador). E, apesar de ser uma construção um tanto bizarra, ela funciona melhor do que nossa tentativa inicial:

#ifdef NDEBUG
 
#define MYTRACE( message ) /* nothing */
 
#else
 
#define MYTRACE( message )        \
	do                             \
	{                              \
		char buffer[500];           \
		sprintf(buffer,             \
			"MYTRACE: %s(%d) %s\n",  \
			__FILE__,                \
			__LINE__,                \
			message);                \
		printf(buffer);             \
	}                              \
	while( 0 )
 
#endif /* NDEBUG */

Ao usar um do-while (com uma expressão que retorna falso dentro do teste, de maneira que o código seja executado apenas uma vez) a construção if-else consegue funcionar perfeitamente:

if( exploded() )
	do
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"Oh, my God");
		OutputDebugString(buffer);
	}
	while( 0 );
else
	do
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"That's right");
		OutputDebugString(buffer);
	}
	while( 0 );

Projeto Orientado a Componentes, parte II

2008-05-08T16:28:23+00:00

Quando dizemos que componentes são por definição intercambiáveis estamos continuando uma longa tradição de bons projetistas de bons sistemas, cujo conjunto de características sempre integrará, por mais sofisticada a metodologia e/ou a nomenclatura, a aplicação da separação entre interface e implementação. [1]

Se a interface continua a mesma, podemos substituir a implementação sem perturbar o comportamento do sistema. Obviamente que o comportamento do sistema deve mudar de alguma forma, senão trocar a porcaria do componente não teria propósito. Esperamos, portanto, que erros sejam corrigidos (de modo que o sistema de fato funcione como deveria), ou que o desempenho aumente (de modo que o sistema funcione antes que eu caia no sono) ou sei lá.

Aplicávamos esta distinção já na era do projeto estruturado; e no projeto essencial; e no projeto orientado a objetos; e agora no projeto orientado a componentes e aplicaremos no projeto orientado a serviços quando finalmente este troço alcançar a plebe.

Em um sistema orientado a objetos, nós temos tipicamente dois elementos em evidência como detalhe de implementação: a estrutura de um objeto, e as instruções levadas a cabo por seus métodos. Nós queremos liberdade para alterar a estrutura de um objeto e queremos liberdade para alterar a instruções executadas por seus métodos. (Há mais por debaixo do pano, como sempre.)

Em um sistema orientado a componentes, um terceiro elemento surge ofuscando, como se fosse, os outros dois; o componente propriamente dito. Entendemos que um componente possui uma interface e uma implementação; sendo a implementação de um componente composta por inúmeras classes. Além disso, um componente é um artefato componente (heh) de um sistema implantado; é parte da definição de componente que este seja intercambiável por um outro, que implemente a mesma interface, em um sistema implantado -- em contraste com um tipo de substituição que exige recompilação.

Esta última restrição, quando posta no contexto dos sistemas operacionais reais, com seus linkers e loaders reais, nos trás à crux do problema de projeto orientado a componentes: a implementação de uma classe integrante de um componente absolutamente não pode depender de um detalhe de implementação de uma classe integrante de outro componente.

Observe que esta restrição não é exatamente uma novidade, já que bons sistemas isolarão módulos através de interfaces para aumentar a coesão e diminuir o acoplamento; porém, quando componentes entram na jogada, a metodologia exige uma restrição mais forte.

(De fato, esta restrição metodológica se torna uma impossibilidade tecnológica assim que os componentes são levados ao próximo estágio, passam a não mais morar no mesmo espaço de memória virtual, e começam a ser chamados "distribuídos" ou "serviços".) [2]

É por esta razão que os líderes do Projeto Spaghetti falharão em "componentizar" seu sistema; mesmo que, à primeira vista, seja possível seccionar sua estrutura de classes em artefatos binários distintos.

[1] Nós, filhos da cultura européia, nem escrevendo programas nos livramos da dicotomia corpo versus espírito. Nem imagino o que seria uma metodologia de desenvolvimento de sistemas desenvolvida por monges taoístas chineses.

[2] E portanto, domar a restrição metodológica significa poder conviver com a impossibilidade tecnológica e eventualmente programar os sistemas do futuro.

Projeto Orientado a Componentes, parte III

2008-05-08T16:28:08+00:00

Agora, uma pausa para reflexão. Esta dicotomia interface versus implementação é difícil de definir. Por baixo dos panos nós temos memória de onde nós lemos e para onde nós escrevemos. O que caracteriza uma interface e o que a distingue de uma implementação?

Essa pergunta só pode ser respondida em um determinado contexto. Um bom sistema escrito em assembler talvez tenha interfaces mais bem definidas que um mau sistema escrito em Java. Porém, está claro para a indústria que certos mecanismos de linguagem favorecem o estabelecimento de boas interfaces no sistema implementado.

Além disso, a noção de interface surge diante de um problema de substituição. É interface aquilo que, mantendo-se estável, permite a substituição daquilo que é implementação. Porém, o que é este permite? Este permite, quando caracterizado, por conseguinte caracteriza o que é interface.

Suponha um sistema escrito em C++ por uma equipe que considera irrisório o tempo de recompilação do código-fonte. Neste contexto, podemos seguramente aceitar que a seguinte substituição mantém estável uma interface.

antes


class Foo {
public:

Foo ();

void
mutate_stuff ();

int
observe_stuff () const;

private:
Bar* m_bar;
};

depois


class Foo {
public:

Foo ();

void
mutate_stuff ();

int
observe_stuff () const;

private:
int m_cache;
shared_ptr<bar> m_bar;
};

Após a alteração acima e uma recompilação o sistema continua a funcionar normalmente. [1] Dizendo de forma mais extensa: neste contexto, a substituição realizada não altera propriedades observáveis externamente da classe, de modo que do ponto de vista de um observador, a classe mantém estável sua interface. (Apenas membros privados foram alterados.)

Agora vamos alterar as nossas premissas. O tempo de recompilação desse sistema é enorme e o ciclo de testes não pode esperar, de modo que a estrutura de classes do sistema foi particionada e esta classe mora dentro de um objeto compartilhado, uma biblioteca dinâmica.

A equipe realiza a substituição, recompila o objeto compartilhado e o entrega a uma equipe de testes.
E os testes falham miseravelmente.

Isto acontece porque, neste novo contexto, há mais propriedades observáveis a considerar, que devem se manter estáveis -- que fazem parte da interface da classe.
Neste caso, o layout de um objeto da classe Foo é uma propriedade observável; um programa compilado criando objetos da definição antes criará objetos com um layout diferente daquele esperado pelo objeto compartilhado que espera objetos dada a definição depois.
A definição depois tem um int no offset onde a definição antes tinha um ponteiro, ela ocupa mais memória etc.

Podemos dizer que o primeiro caso é o caso de um projeto orientado a objetos, onde a alteração de elementos privados da classe não altera a interface; e podemos dizer que o segundo caso é o caso de um projeto orientado a componentes, onde a alteração do layout na memória de uma classe altera sua interface.

Como no segundo caso nós estamos violando a interface do componente, nós não podemos substituir o componente de antes pelo componente de depois impunemente. Dito de trás para a frente, pelo fato de não podermos substituir o componente de antes pelo componente de depois, por definição estamos violando sua interface.

Imagine então o que acontece em um sistema spaghetti, onde todas as classes mantém referência a todas as outras classes; uma violação de interface em um "componente" perturbará implacavelmente todos os outros "componentes".

Quando projetamos um sistema pensando em componentes, ou quando desejamos aplicar a idéia forte de interface para melhorar o nosso projeto diminuindo o acoplamento entre as coisas que são distintas, é útil usar das ferramentas à disposição para dar forma ao que é uma interface.

Linguagens que se propõe a facilitar o desenvolvimento de componentes, como Java e C#, possuem como parte integrante do seu vocabulário e mecanismo nativo uma interface em contraste com as classes. Normalmente algo do tipo:


interface IFoo {

void
mutate_stuff ();

int
observe_stuff () const;

};

Em C++ não existe uma construção análoga mas é possível emulá-la integralmente usando classes, da seguinte maneira:


class IFoo {

virtual
void
mutate_stuff () = 0;

virtual
int
observe_stuff () const = 0;

};

(O leitor astuto observará que esta construção-interface não possui atributos.)

O propósito de usar construções como estas é evidenciar a natureza destes elementos como interfaces -- aquilo que se deseja manter estável -- e diminuir a chance disto que é interface ser inadvertidamente alterado -- causando o desastre. A construção-interface é a melhor amiga do projetista de componentes, permitindo a representação de um conceito de projeto diretamente na linguagem do código-fonte, restringindo as possibilidades de violação durante o processo de implementação, ou ao menos tornando a (necessidade de) violação claramente evidente.

Infelizmente para nós nem tudo que existe na fronteira de um componente pode ser uma interface, já que é preciso comunicar coisas de um componente para outro. E quem pode viver comunicando apenas doubles e bools? Nós queremos comunicar objetos.

Além disso, as construções-interface não são garantia de estabilidade de interfaces, já que há mais sobre o que é publicamente observável em um objeto que sua estrutura: há o seu comportamento.

[1] Estamos, naturalmente, assumindo que o programador não é louco e que a alteração tem algum sentido, exatamente como aparenta ter.

Projeto Orientado a Componentes, parte IV

2008-05-08T16:27:55+00:00

Uma ligeira digressão, para aproveitar a oportunidade que se apresenta; apresentei esta semana um brevíssimo seminário sobre interoperabilidade entre C++ e Java (com ênfase na ferramenta SWIG).

O problema a resolver, quando a necessidade de interoperabilidade entre C++ e a Java surge, é exatamente um problema de projeto de componente, por uma via indireta: se não é tão necessária a garantia de substituição de componentes, é inescapável a completa separação entre a implementação do "componente C++" e do "componente Java" devido ao completo isolamento entre seus espaços de memória.

Esta mesma situação ocorre em um sistema convencional de componentes em que cada componente se localiza em processos distintos, ou mesmo em sistemas distintos, se comunicando através de algum mecanismo inter-processos. O próximo passo na escala evolutiva do projeto de sistemas, o projeto orientado a serviços, lida explicitamente com esta situação, já que se assume como normal que serviços se localizam em sistemas (portanto processos) distintos.

Esse contexto, e as restrições que ele impõe, transforma a natureza da troca de informação; a memória de um processo não é mais um recurso compartilhado entre rotinas.

Considere a seguinte função em C, parte de uma interface de componente IFoo. (O componente concreto Foo implementa a interface IFoo.)


  Foo*
  foo_retrieve_from_persistence (char* foo_name);

Esta função recebe uma NTBS identificando unicamente um objeto Foo na persistência e retorna o endereço do objeto Foo na memória, trazendo o objeto para a memória uma primeira vez se necessário.

Suponha que seja desejável, através de um programa Java, usar objetos Foo obtidos através desta função.

Do componente Bar, uma operação obtém uma referência a uma implementação de IFoo e decide chamar a operação foo_retrieve_from_persistence, passando como argumento uma NTBS. Observe que uma NTBS é uma referência a um espaço contíguo de memória; simplesmente entregar esse endereço para o componente Foo causará um desastre quando este componente resolver acessar esse endereço em seu próprio espaço de memória, cujo significado é incerto. Do mesmo problema sofre o valor de retorno da função; este é o endereço de um objeto na memória do componente Foo, cujo significado no espaço da memória de Bar é incerto.

Essa situação exibe a impossibilidade de tratar a semântica de referência, na travessia do limiar entre componentes, da mesma maneira como é tratada em projetos mais simples. Como já dissemos, não é possível assumir a memória como recurso compartilhado entre operações em um projeto orientado a componentes. [1]

A solução canônica é copiar esses valores. Esta tarefa deve ser realizado por aquele elemento do sistema que existe no umbral entre componentes e é responsável por transportar informação de um lado para o outro. Este elemento deverá, então, copiar todo o segmento de memória endereçado por foo_name da memória do componente Bar para a memória do componente Foo. Esta atividade se denomina "data marshalling" em um certo vocabulário e regras particulares de "data marshalling" são chamadas "type maps" em um certo outro vocabulário.

Este é um exemplo simples de "type map" que transporta um objeto String do Java para um argumento de tipo const std::string& do C++.


  // na prática, estes objetos são argumentos de uma função JNI.
  extern JNIEnv* jenv;
  extern jstring jargN;

  // type map
  const char *argN_pstr = (const char *)jenv->GetStringUTFChars(jargN, 0);
  if (!argN_pstr) return 0;
  std::string argN_str(argN_pstr);

A função GetStringUTFChars realiza a tarefa concreta de copiar os segmentos de memória do espaço de memória Java para o espaço de memória C++. Assim, a operação da interface de componente Java/JNI terá a seguinte forma:


  public static native jlong foo_retrieve_from_persistence (String foo_name);

Essa solução, infelizmente, não resolverá o problema do valor de retorno da função. Foo não é um tipo primitivo da linguagem; não existe uma função na JNI para copiar objetos Foo. Mesmo que existisse, Foo é um objeto; o que nós queremos fazer com ele é chamar suas operações. De certa forma, nossa vontade se divide em duas: expor ao programa Java as operações da classe Foo e expor ao programa Java objetos Foo sobre o qual operar. Essas duas necessidades serão resolvidas com mecanismos diferentes.

Digamos que esta seja a classe Foo.


class Foo {
public:

    Foo (char* name);

    char*
    ask_question (char* question);

    char*
    get_name () const;

};

A primeira vontade é realizável produzindo, para cada operação de Foo, uma operação na interface do componente IFoo.


    Foo*
    Foo_new (char* name);

    void
    Foo_delete (Foo* foo);

    char*
    Foo_ask_question (Foo* foo, char* question);

    char*
    Foo_get_name (const Foo* foo);

A segunda é entregando ao programa Java o endereço do objeto Foo necessário. Chegamos, aparentemente, a um impasse; já que nosso problema original era justamente como transportar o valor de retorno da função foo_retrieve_from_persistence, que é do tipo Foo*! Porém, tendo caminhado até aqui, o problema se torna ligeiramente diferente, e uma solução é possível. Agora que nós temos todas as operações de Foo que desejamos exportadas pela interface de componente IFoo, tudo o que resta é entregar ao componente cliente uma referência opaca a um objeto Foo. O componente cliente da interface nunca necessitará resolver (ou de-referenciar) esta referência; ele apenas mantém este valor para usá-lo como argumento de chamada a uma operação da interface IFoo. [2]

Endereços de memória do C++ podem ser guardados apropriadamente na memória do Java como um valor do tipo Long. Assim, o valor de retorno da operação Foo_create é resolvido pelo seguinte "type map":


  // este é o objeto retornado pela chamada JNI
  jlong jresult = 0;
  // este é o objeto retornado pela função C++
  Foo* result = NULL;

  // type map
  result = new Foo(arg1_str); // vide type map anterior
  *(Foo **)&jresult = result;

  // por fim...
  return jresult;

e a operação na interface de componente Java/JNI terá a seguinte forma:


  public static native jlong Foo_create (String name);

Assim, o programa Java chamador de Foo_create através desta interface receberá um valor Long que contém o endereço, na memória do C++, do objeto Foo recém-criado. A operação Foo_get_name através desta interface terá a seguinte forma:


  public static native String Foo_get_name (jlong foo);

sendo que o valor de retorno da operação Foo_get_name do componente IFoo será "marshalled" pelo "type map" como já vimos anteriormente.

Havendo resolvido o problema da possibilidade de referenciar, de maneira opaca, um objeto Foo da memória do C++ na memória do Java, e o problema de chamar operações da classe Foo em C++, podemos então criar uma classe Foo em Java cujo único propósito é imitar a classe Foo em C++ por conveniência.


class Foo {

  private Long cPtr;

  // @Override
  public void finalize () {
    delete();
  }

  public void delete () {
    IFooJNI.Foo_delete(cPtr);
  }

  public Foo (String name) {
    cPtr = IFooJNI.Foo_new(name);
  }

  public String ask_question (String question) {
    return IFooJNI.Foo_ask_question(cPtr, question);
  }

  public String get_name () {
    return IFooJNI.Foo_get_name(cPtr);
  }

};

Desta forma concretizamos uma forma ideal de interoperabilidade entre Java e C++ onde, para cara classe C++, há uma classe Java equivalente, responsável por esconder as chamadas à interface de componente JNI que, por sua vez, é responsável por realizar o transporte de informação através do umbral dos componentes.

Nestes exemplos ocultamos o fato de que, para a JNI, é necessário não somente um componente Java/JNI mas também um componente C++/JNI além do próprio componente que implementa a interface IFoo; também não lidamos com os casos em que registramos "objetos callback" criados no Java em sistemas C++; não lidamos com a vontade de transportar exceções disparadas em C++ de volta para o chamador Java; entre outras coisas de que não falamos.

[1] É claro que um projeto pode se utilizar da noção de componentes de uma forma restrita, para obter um conjunto restrito de benefícios, abandonando esta restrição; é possível, por exemplo, obter os benefícios de recompilação veloz e carga de código por demanda abandonando a possibilidade de distribuir os componentes de modo a mantê-los sempre no mesmo espaço de memória e permitir o uso convencional de ponteiros.

[2] Em projetos de sistemas com componentes é comum que esta idéia do "endereço opaco" seja generalizada para qualquer tipo de informação "opaca" que seja capaz de identificar univocamente um objeto de Foo no domínio do componente Foo; por exemplo, um "nome", ou um GUID, ou outra coisa qualquer.

Projeto Orientado a Componentes, parte I

2008-04-28T22:59:19+00:00

Ano passado fiz um curso de extensão em Projeto Orientado a Componentes com UML; na época, eu estava progredindo na minha capacidade de construir modelos mentais de projetos de software orientados a objeto e já havia lido bastante sobre web services e arquiteturas orientada a serviços.

O mais interessante sobre os Componentes é a maneira como eles dão um nó na sofisticação aparente dos sistemas e obrigam o projetista a voltar aos básicos. Digo isso porque estes sistemas são aparentemente sofisticados; na prática, eles apresentam baixa coesão e alto acoplamento, significando que elementos deste sistema se relacionam diretamente com praticamente todos os outros de maneira ad hoc, fenômeno que, em sua forma mais concreta, denomina-se código spaghetti.

É possível construir um sistema orientado a objetos onde todos os objetos conhecem ponteiros para todos os outros, ou praticamente todos os outros, usando truques safados como embrulhar todo mundo em shared_ptr e tornando todas as classes enable_shared_from_this e olerê olará. Isto, é claro, se você tem um mínimo de conhecimento sobre C++ contemporâneo -- e se você está de fato escrevendo seu sistema em C++! -- e se você se importa com a memória. O sistema acima é "orientado a objetos". Muitos deles, embolados entre si.

Quando você se propõe a fazer sistemas orientados a componentes, porém, o buraco se alarga e se torna mais profundo. Os componentes existem com o propósito de serem intercambiáveis. Você não tem componentes se você não pode tirar um deles e colocar outro no lugar impunemente.

Frequentemente, os responsáveis por sistemas spaghetti ou aberrações similares, diante dos problemas insuportáveis causados inevitavelmente pela baixa coesão e pelo alto acoplamento, tentam "componentizar" seus sistemas com o intuito de obter os benefícios maravilhosos oferecidos pelos livros.

Vamos, então, pegar pedaços do sistema e enfiar dentro de DLLs!

Certamente isto não funciona.

Seminário CCPP Portabilidade e Performance

2008-04-25T13:32:32+00:00

Reserve sua cadeira. Está marcado para o último dia do mês de maio o primeiro seminário de nosso grupo nacional de programadores e aficionados por C e C++. É bom ou não é?

O assunto gira em torno de duas preocupações constantes na vida de todo programador de linguagens de nível médio:

Quanta velocidade eu preciso nesse código?
Em quais plataformas eu conseguiria compilar e rodar meu projeto?

Para responder estas questões teremos uma bateria de palestras com temas que, dessa vez, focam o simples, puro e independente uso das linguagens C/C++:

Dicas e Truques de Portabilidade
Wanderley Caloni

O objetivo dessa palestra é focar nos problemas da vida real que enfrentamos no dia-a-dia para tornar um código portável ou mais maleável para um dia ser. Nesse caso existem vários assuntos a tratar, como: construções ambígüas não-padrão, isolamento de particularidades de cada sistema, identificação de problemas de portabilidade, organização do código-fonte portável, entre outros.

O nível dessa palestra será o intermediário, porque eu preciso que o público tenha o conhecimento prévio de programação C e C++. Quando você está aprendendo, uma dica ou outra sobre portabilidade pode ser interessante para não ser desvirtuado desde o início. Porém, para realmente começar a programar multiplataforma, existem desafios que devem ser transpostos por aqueles que já conseguem um nível de organização e desenvolvimento em C e C++ que não deixa dúvidas sobre a qualidade do código.

Programação Concorrente com C++
Fábio Galuppo

Fábio Galuppo estréia na nossa rede de palestrantes, depois de seu inspirador e excitante relato das peripécias do SD West desse ano. Ele irá falar de um tema extremamente atual, que é o uso de programação paralela, em especial usando C++. Existe uma série de coisas para entender, como os modelos a ser seguidos, o uso consciente de threads, a programação com bom desempenho nos novos chips com mútiplos núcleos de processamento e por aí vai.

Apenas para ter uma idéia da importância em se ir em uma palestra como essa, imagine que 99,9% dos produtos da Google se baseiam nesse tipo de programação, envolvendo uma plantação de algumas centenas (milhares?) de máquinas trabalhando um banco de dados gigantesco no modo cooperativo para entregar a resposta mais rápida possível do outro lado. Sentiu o drama?

Programação Multiplataforma Usando STL e Boost
Rodrigo Strauss

Voltando para o tema portabilidade, Rodrigo Strauss volta a repetir sua performance sobre Boost, dessa vez abrangendo o conjunto completo de bibliotecas que compõem essa extensão mais-que-necessária da STL para programadores produtivos e multiplataforma. Todos sabem que um código que apenas usa STL e C++ puro não consegue ir muito longe na vida real, apesar de ser 100% multiplataforma. O que muitos não sabem (inclusive eu) é como é possível turbinar o desenvolvimento portável com o uso do Boost, que é uma solução portável bem interessante.

Por exemplo, a manipulação de arquivos e diretórios não é lá o forte da STL, concentrada no conceito de streams. Com o uso do Boost, podemos ter o melhor da STL, só que turbinada. Além disso, o novo padrão de threads ainda está longe de chegar ao mercado, e o Boost.Threads é uma solução viável atualmente.

Técnicas de Otimização de Código
Rodrigo Kumpera & André Tupinambá

Essa é a estréia de dois palestrantes de uma só vez! Como um bom complemento, voltamos ao tema de otimização, dessa vez em aspectos mais genéricos. Entre questões mais ou menos banais como otimização de laços e benchmarkers, mas que faze toda a diferença saber, teremos ainda tópicos bem avançados, como a relação de nosso código com o cachê do processador, e a tão-falada técnica de branch prediction, presente na maioria dos processadores atuais.

Além do aspecto genérico teremos uma pitada de matemática, como o uso de lookup tables e a otimização de algoritmos baseada em operações vetoriais. Ainda como um aspecto básico, mas importante, temos o uso eficiente da memória, muitas vezes entregue ao controle do sistema operacional, que nem sempre sabe bem o que o programa está fazendo.

Ode ao C++

2008-04-21T11:06:34+00:00

Strauss: lembra quando nós conversávamos sobre o assunto "Por que C++?", há muitas décadas atrás, e seu blogue era um dos primeiros no Brasil que não ficava relatando o que o autor comia no café da manhã, além de falar sobre programação? Pois é, eu estava reorganizando meus g-mails e reencontrei nossa conversa e, pior, seu artigo "derivado" dela, que irei republicar aqui pois, assim como antes, acredito em tudo que escrevi naquela época.

(direto do "Contato do Site")

Cristiano -- Olá! Sou programador em basic (Vbasic/Qbasic), fico indignado, com
pessoas que sabem enteder a linguagem C++, assembler... Como podem? Eu
acho isto coisa de outro mundo! Será que eu tenho chances de aprender
a linguagem?

Strauss -- A resposta é simples: estudando. Eu tb comecei com QBasic e VB. Arrume um livro de C++ e estude. Treine bastante. E hoje em dia é mais fácil do que quando eu comecei, pq eu não tinha acesso à Internet. É simples assim...

Caloni -- Você pode ir tão longe quanto queira, mas pra isso a primeira coisa que vc tem que fazer é querer =).

Strauss -- Acho que vou fazer um post sobre isso. "Por que C++" Vc podia me ajudar...

Caloni -- Escrevi um textículo sobre o assunto da escolha, mas não visando o mercado:

/**

* @title Por que C++

* @author Wanderley Caloni Jr

* @date 31.01.2005

É natural que um programador tenha preferência por uma linguagem.
Geralmente por motivos pessoais que se refletem nas características da
linguagem. Eu, por exemplo, tenho vários motivos para amar essa
linguagem:

Linguagem C. Todas as vantagens da linguagem C estão embutidas em C++.
E sem aquele papo erudito que deve-se programar em OO para ser C++.
Por ser multiparadigma, a linguagem também suporta o melhor da
programação procedural e estruturada.

Popularidade. C++ é o que há. Linguagem unânime e reconhecida no mundo
todo como de uso geral. Dificilmente você vai encontrar um algoritmo
que não tenha representação em C++.

Economia e Expressividade. Pode parecer bobagem, mas coisas como
operador de incremento e valor em todas expressões permite que se faça
muita coisa com poucas linhas. Isso a torna muito expressiva. Isso, em
outras palavras, quer dizer que você pode juntar várias expressões
numa só, e esse conjunto será também uma expressão.

Liberdade. Em C++ você é o culpado de virtualmente qualquer coisa de
bom e ruim que aconteça no seu programa, pois você tem que seguir
poucas regras e tem que ser responsável no que faz. C++ não te ajuda a
seguir um bom modelo de programação com restrições embutidas. Isso a
torna difícil para iniciantes, mas conforme aumenta a experiência,
maior o prazer em programar.

Portabilidade. A possibilidade de compilar e rodar o seu código em
vários ambientes - de compilação e execução - é uma característica
útil e agradável. No meu caso é só agradável, pois dificilmente faço
código portável, apesar das boas noções que tenho sobre o assunto. E
são essas boas noções que me permitem afirmar que C++ suporta muito
bem essa possibilidade.

Rapidez. Pode não ser importante em muitos casos, mas já é do instinto
do programador o desejo de eficiência no código. E nada como programar
numa linguagem extremamente eficiente em tempo de execução para se
sentir feliz de ver o código rodando.

FIM

[]s

Strauss -- Legal. Vou colocar minha água mercadológica no feijão e colocar no site.

Nos dias de hoje...

Não quis alterar o texto original, mas colocaria, além de rapidez, o título economia de recursos. É incrível o quanto progredimos no quesito hardware todos esses anos, e mesmo assim, existem linguagens e ambientes que parecem ter fome suficiente para consumir tudo e deixar um computador de última geração parecer um micro "meio lerdinho". Felizmente não preciso dar nome aos bois, pois todos sabem ou conhecem pelo menos uma linguagem com essa característica.

Também não quis generalizar. C e C++ não são as duas únicas opções quando se fala em bom desempenho. Existe também assembly e linguagens de script, que chegam inclusive a ser mais flexíveis e rápidas (além de mais produtivas).

Ainda acredito em tudo isso que C++ proporciona e irá continuar proporcionando por muto tempo. Para os que não seguiram o linque do artigo do Strauss, existe uma modesta lista de programas escritos nessa linguagem ao redor do planeta. Muitos são conhecidíssimos e usados nos quatro cantos do mundo, muitas vezes em mais de um sistema operacional. C++ está morto? Longe disso... talvez pareça assim em território nacional, mas esse é o motivo de meus votos de sucesso no início de nosso grupo C++.

Projeto: Eclipse + CppUnit

2008-04-06T20:30:52+00:00

Estou prestes a apresentar para o ccppbrasil.org um projeto de integração da CppUnit com o Eclipse TPTP.

Será uma oportunidade interessante de aprender a desenvolver sobre a plataforma OSGi e uma maneira de estimular a comunidade a aplicar as técnicas de testes de unidade.

A arquitetura do TPTP Test é assim: para um determinado "tipo de teste" registra-se um adaptador de implantação, um adaptador de ambiente e um adaptador de execução, bem como um runner para este "tipo de teste" no agente remoto.

A tarefa será implementar esses adaptadores para programas executáveis nativos e bibliotecas compartilhadas, resolvendo LD_LIBRARY_PATH e assuntos relacionados, depois implementar uma biblioteca de suporte em C para que programas joguem na saída padrão o histórico de execução da forma correta e por fim implementar com um wrapper Java um runner para suites de teste CppUnit na forma de plug-in.

Na verdade as tarefas ainda estão se abrindo porque não consegui dominar o problema de projeto completamente, o que me aborreceu um pouco, já que vou passar a semana ocupado com outros assuntos.