Properties no C++

[Thiago Adams]

Acho que o título já explica o propósito deste tópico considerando
a existencia deste conceito (ou similar) em outras linguagens como C#.

Em resumo, gostaria de ter uma interface na classe aonde:

int i = x.prop;
x.prop = 1;

fosse equivalente a

int i = x.get_prop();
x.set_prop(1);

Nas expressões aonde x.prop é rvalue ele é equivalente a x.get_prop e
também o mais equivalente possível comparado como se prop fosse um
objeto publico do tipo da propriedade.

Aonde x.prop é lvalue ele pode ser definido como set_prop (algo ) ou
outra coisa (+=, ++).

Diferente do C#, no C++ podemos ter sobrecarga do operator =. Por
exemplo,
std::string pode ser setado para uma std::string ou para uma string
literal.
Eu quero ter sets diferentes para cada sobrecarga.

Considerando vários casos fiz o seguinte código

http://www.thradams.com/codeblog/properties.htm

que ainda está incompleto, faltam operadores, e mais tarde ele vai
passar por uma fase de
como tornar o uso fácil.

Cada propriedade não vai consumir memória. O ponteiro do é descoberto
"pai" fazendo o offset do this da propriedade.

Ainda tem bastante coisa para implementar e definir. Sugestões casos
de usos, problemas são bem vindos.

Se alguém mais quiser ajudar a especificar o comportamento e
implementação seria interessante também.
Quem sabe depois montar uma proposta para uma sintaxe que simplifique
isso no C++.

[Rodrigo Madera]

Da uma olhada na impl da STLSoft:  http://www.stlsoft.org/doc-1.9/group__group____library____properties.html

Talvez te inspire em alguma coisa.

Mx

2012/1/17 Thiago Adams <thiago...@gmail.com>

--
Antes de enviar um e-mail para o grupo leia:
                    http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
             para Eventos do Grupo C & C++ Brasil:
                       http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

[Jardel Weyrich]

Bacana Thiago!

Eu gosto dessa implementação da ACCU - http://accu.org/index.php/journals/255

Dá pra tirar umas boas idéias de lá.

2012/1/17 Thiago Adams <thiago...@gmail.com>

[Уθя¡ςκ]

Outra coisa tb, a BOOST tem uma lib que faz o serviço sujo de
implementação de operadores a partir de uns poucos fundamentais:
http://www.boost.org/doc/libs/1_38_0/libs/utility/operators.htm

[Rodrigo Madera]

2012/1/17 Уθя¡ςκ <obl...@gmail.com>

Outra coisa tb, a BOOST tem uma lib que faz o serviço sujo de
implementação de operadores a partir de uns poucos fundamentais:
http://www.boost.org/doc/libs/1_38_0/libs/utility/operators.htm

Bem lembrado!

Mas eu usaria a documentação atual:  http://www.boost.org/doc/libs/1_48_0/libs/utility/operators.htm

Vai que tem alguma coisa atualizada.

[Thiago Adams]

On Jan 17, 4:55 pm, Jardel Weyrich <jweyr...@gmail.com> wrote:
> Bacana Thiago!
>

> Eu gosto dessa implementação da ACCU -http://accu.org/index.php/journals/255

> Dá pra tirar umas boas idéias de lá.

Obrigado pelo link.
Acredito que minha implementação vai ser bem mais completa que esta.

Nesta implementação quando prop for uma std::string

e você faz:
x.prop = "a";

primeiro ele cria uma std::string nova com o "a" e depois ele copia
para a string dentro da propriedade.
No meu caso, é feito diretamente. (Feito para suportar) Esta
implementação também é muito especifica para o tipo de get e set. Por
exemplo retornar copia de string no get sem necessidade.

e se voce faz:

x.prop == "a" nem compila

acredito que o outro link tenha os mesmos problemas mas não testei.
Basicamente a propriedade no C++ nao pode ter um tipo unico para get e
set e é isto que as
implementações estão fazendo.

[Thiago Adams]

Acho que a essência do que quero pode ser representada por este
código.

x.prop = x.prop + value;

seja como:

x.set_prop( x.get_prop() + value )

seja o que for o objeto retornado por get_prop, e seja qual for a
operação + definida para o tipo value
e seja qual for o tipo resultante, vai chamar a melhor opção de
set_prop.

Não é preciso apenas uma set_prop (como no C#) e nem um caso
especifico de operator +.

template <class T>
friend auto operator +(const TProp& a, const T& value) ->
decltype( a.ptr()->get_prop() + value)
{
return a.ptr()->get_prop() + value;
}


(este código não está compilando com std:string no VC++ 10,
porém isso também não vai trancar o desenvolvimento da ideia)

Até agora não tive nenhum caso aonde não consiga o resultado que
desejo como comportamento.

[Rodrigo Madera]

Sem dúvida nenhuma usa os recursos tão novos como você.

Pode ter futuro tua lib, heim!

Mx

2012/1/17 Thiago Adams <thiago...@gmail.com>

[Thiago Adams]

On Jan 17, 5:37 pm, Rodrigo Madera <rodrigo.mad...@gmail.com> wrote:
> Sem dúvida nenhuma usa os recursos tão novos como você.
>
> Pode ter futuro tua lib, heim!
>

Eu já estou usando inclusive..
No caso atual estou usando em interface abstratas:


struct Interface
{
virtual int get_width() = 0;
virtual void set_width(int) = 0;
virtual void set_width(double) = 0;

struct
{
...
template<class T>
operator = (const T& value)
{
r().set_width(value);
}
} width;
};

Aguém implementa esta interface e quando chamo x.width na verdade é
uma função virtual.
o set_ chamado é o melhor disponível, mas no caso de interface
abstrata cada set_ tem que ser declarado.
No caso não abstrato daria para deixar o set como template também. (só
passa o value adiante)

[Rodrigo Madera]

Pra incentivar o uso da tua biblioteca, seria legal você ter uma Wiki (ou algo assim) descrevendo exemplos.

Eu raramente usaria, pois afeta a sintaxe à qual estou acostumado, mas pode acabar sendo interessante se simplificar entidades de mensagens, por exemplo, que podem ser enviadas para um transporte de rede.

As possibilidades estão por ai.

Boa sorte!

Mx

2012/1/17 Thiago Adams <thiago...@gmail.com>

[Thiago Adams]

On Jan 17, 5:51 pm, Rodrigo Madera <rodrigo.mad...@gmail.com> wrote:
> Pra incentivar o uso da tua biblioteca, seria legal você ter uma Wiki (ou
> algo assim) descrevendo exemplos.
>
> Eu raramente usaria, pois afeta a sintaxe à qual estou acostumado, mas pode
> acabar sendo interessante se simplificar entidades de mensagens, por
> exemplo, que podem ser enviadas para um transporte de rede.

Acho que um design correto em um programa C++ ( o que estou usando )é
ter esta interface "side-by-side" com gets e sets.

Fica a escolha do programador escrever

x.prop = 1;
ou
x.set_prop(1);

caso não fosse possível a classe não estaria sendo "legal" com o
usuário. Por exemplo, se set_prop fosse private.
Acredito que o resultado final desejado tem que poder ser definido em
termos funcoes publicas apenas.

[Reuben Morais]

Interessante sua ideia. Dá pra implementar de forma bem simples (porém
levemente verbosa).
Prototipando rapidamente cheguei nisso aqui: http://codepad.org/CQAofnZi

Só incluí os operadores de escrita e acesso básicos pra ficar curto.
Também dá pra especializar a classe Property para se comportar como
somente leitura, por exemplo.

Tentei também uma sintaxe mais curta e parecida com C#:

int x_;
Property<int> x {
.get = [this] {
return x_*2;
},
.set = [this] (int rhs) {
x_ = rhs*2;
return *this;
}
}

Mas infelizmente o Clang ainda não suporta expressões lambda com a
nova sintaxe e nem generic initializer lists.
Vou deixar salvo e experimentar no futuro :-)

-- reuben

[Thiago Adams]

Fiz um update

http://www.thradams.com/codeblog/properties.htm

Percebi que x.caption == x2.text
mesmo sendo ambas string nao poderiam ser comparadas
por serem tipos diferentes de propriedades.
Neste caso (e outros) tive que colocar uma especie de tag dispatching.

(compilado no VC++ 2010)

Eu gostaria de descobrir o tipo retornado por uma get_xx mas não
consegui ainda então este tipo esta sendo informado na mão por
enquanto.

[Thiago Adams]

On 17 jan, 23:31, Reuben Morais <reuben.mor...@gmail.com> wrote:
> Interessante sua ideia. Dá pra implementar de forma bem simples (porém
> levemente verbosa).
> Prototipando rapidamente cheguei nisso aqui:http://codepad.org/CQAofnZi
>
> Só incluí os operadores de escrita e acesso básicos pra ficar curto.
> Também dá pra especializar a classe Property para se comportar como
> somente leitura, por exemplo.

Você não acha que vai consumir muita memória?
Testa com std::string, operator == , com outras assinaturas de get e
set.
O que você colocou é mais ou menos o que tem no link do accu e tem os
mesmos problemas que eu disse lá.

[Reuben Morais]

2012/1/18 Thiago Adams <thiago...@gmail.com>:

> Você não acha que vai consumir muita memória?

Acho! :-)

Aquilo foi só uma brincadeira, achei interessante a ideia.
Acho que algo como:

typedef T& (Parent::*get_fn)();
typedef void (Parent::*set_fn)(T&);

self& operator=(T&& n) {
(parent->*setfn)(n);
return *this;
}

operator const T&() {
return (parent->*getfn)();
}

Funcionaria bem com strings. E você pode sempre especializar a classe
para necessidades mais específicas.

-- reuben

[Thiago Adams]

É meio irritante ver um monte de templates para uma coisa que o
compilador
poderia fazer de uma maneira muito mais fácil.

Testei a __declspec(property) do visual C, e faz exatamente o que é
para fazer.
Inclusive chama o set mais adequado. Só que não é padrão.

struct X
{
std::string m_name;

const std::string& getName() const
{
return m_name;
}

void setName(const std::string&s) { }

void setName(const char*psz) {
}

__declspec(property(get = getName, put = setName)) std::string
name;
};

x.name = "a";
x.name = x.name;


"When the compiler sees a data member declared with this attribute on
the right of a member-selection operator (" ." or " ->"), it converts
the operation to a get or put function, depending on whether such an
expression is an l-value or an r-value. In more complicated contexts,
such as " +=", a rewrite is performed by doing both get and put. "

[Thiago Adams]

Consegui deixar operadores binarios genericos.(compila e funciona vc++
2010)

auto result = x.prop + algo
algo + x.prop
x.prop + x.prop

Nestes 3 casos x.prop é lvalue.

O objetivo no final das contas é sempre trocar x.prop por x.get_prop
quando
x.prop fosse um lvalue (se fosse um dado direto publico)

Pegando um caso de soma:

template <class T1, class T>
auto operator +(const T1& a, const T& b) ->
typename std::enable_if < std::is_convertible<T1,
Property>::value &&
!std::is_convertible<T, Property>::value, decltype(a.Get() +
b) >::type
{
return a.Get() + b;
}

Em português é o seguinte:

Quando tenho uma expressão a + b , e o tipo do lado esquerdo
da expressão é uma propriedade e do lado direito não é então
vou trocar o "a" pela chamada do get , somar com b e retornar
o tipo e resultado de acordo com a.get() + b;
É o mesmo padrão para todos operadores binarios.

[Reuben Morais]

Hah, no GCC consigo fazer

int x_;
Property<int> x {

/* set */
[&](int& rhs) {
x_ = rhs-5;
},
/* get */
[&] {
return x_*2;
}
}

Mas quando é um membro a sintaxe não fica tão legal, com a
inicialização no construtor.

-- reuben

[Adriano dos Santos Fernandes]

On 18-01-2012 10:05, Thiago Adams wrote:
>
> � meio irritante ver um monte de templates para uma coisa que o
> compilador
> poderia fazer de uma maneira muito mais f�cil.
>

Por outro lado, acho desnecess�rio tentar pegar um idioma de outras
linguagens e tentar colocar em C++ a todo custo.

Eu j� escrevi (ou tentei, n�o lembro) h� muito tempo atr�s meus
templates de properties. Tamb�m n�o gostava do Java usar m�todos
getter/setter.

Mas no final das contas, e da�? O m�todo deixa at� muito mais claro o
que est� sendo feito.

Deixa as properties com o pessoal de Delphi e C#. Pra que tentar imitar?
Isso n�o vai adicionar nem clareza nem funcionalidade ao seu c�digo...

Adriano

[Felipe Ferreri Tonello]

On Jan 18, 2012 2:40 PM, "Adriano dos Santos Fernandes" <adri...@gmail.com> wrote:
>
> On 18-01-2012 10:05, Thiago Adams wrote:
> >

> > É meio irritante ver um monte de templates para uma coisa que o
> > compilador
> > poderia fazer de uma maneira muito mais fácil.
> >
>
> Por outro lado, acho desnecessário tentar pegar um idioma de outras

> linguagens e tentar colocar em C++ a todo custo.
>

> Eu já escrevi (ou tentei, não lembro) há muito tempo atrás meus
> templates de properties. Também não gostava do Java usar métodos
> getter/setter.
>
> Mas no final das contas, e daí? O método deixa até muito mais claro o
> que está sendo feito.
>

Concordo

> Deixa as properties com o pessoal de Delphi e C#. Pra que tentar imitar?

> Isso não vai adicionar nem clareza nem funcionalidade ao seu código...
>

Eu acho bobeira complicar para nada. Não vejo nenhum benefício real de se usar properties em C++.

Felipe Tonello

[Rodrigo Madera]

Acho que muitos de nós fez alguma coisa com properties no passado, até por diversão.

Eu mesmo fiz os meus há muitos anos atrás.

Mas de vantagem mesmo, eu também não consigo exergar, e por isso pedi ajuda dos autores aqui para nos iluminar para uns exemplos onde possam ser interessantes.

Pensei, talvez, em entidades serializáveis para comunicação serial. Mas mesmo assim, acho que preciso de um pouco mais de wow-effect.

Por outro lado, o desafio técnico e o prazer de ter conseguido, já valeram a pena para os autores das bibliotecas apresentadas.

Mx

2012/1/18 Felipe Ferreri Tonello <felipe....@gmail.com>

 

--

[Уθя¡ςκ]

Acredito que o que se busca em tentativas semelhantes é expressividade
de linguagem, principalmente no contexto de DSL. Acredito que o mesmo
pensamento de "complicar pra quê" no design original do java foi o que
fez com que a linguagem não tivesse sobrecarga de operadores, já que
com métodos se consegue funcionalmente os mesmos resultados. Só que
uma linguagem ter capacidade de fazer uso de sobrecarga de operadores
e afins, não impede nada na escolha de não utilizá-los. Normalmente é
melhor quando esta escolha fique a seu cargo, do que vc nem se quer tê-
la. Sem sobrecarga de operadores, java não é capaz de expressar
operações sobre matrizes de forma tão intuitiva e natural quanto uma
lib C++ é capaz. O mesmo vale pra properties, em ambos os casos, à
escolha do freguês, a verbosidade pode ser diminuída. E quando essas
formas de expressão casam com o contexto de trabalho, por exemplo, o
contexto matemático das matrizes, melhor.

On Jan 18, 3:38 pm, Rodrigo Madera <rodrigo.mad...@gmail.com> wrote:
> Acho que muitos de nós fez alguma coisa com properties no passado, até por
> diversão.
>
> Eu mesmo fiz os meus há muitos anos atrás.
>
> Mas de vantagem mesmo, eu também não consigo exergar, e por isso pedi ajuda
> dos autores aqui para nos iluminar para uns exemplos onde possam ser
> interessantes.
>
> Pensei, talvez, em entidades serializáveis para comunicação serial. Mas
> mesmo assim, acho que preciso de um pouco mais de wow-effect.
>
> Por outro lado, o desafio técnico e o prazer de ter conseguido, já valeram
> a pena para os autores das bibliotecas apresentadas.
>
> Mx
>

> 2012/1/18 Felipe Ferreri Tonello <felipe.tone...@gmail.com>

>
>
>
>
>
>
>
> > On Jan 18, 2012 2:40 PM, "Adriano dos Santos Fernandes" <

> > [&] C & C++ Brasil -http://www.ccppbrasil.org/

> > Para sair dessa lista, envie um e-mail para
> > ccppbrasil-...@googlegroups.com

> > Para mais opções, visitehttp://groups.google.com/group/ccppbrasil
> > --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> > Emprego & carreira: vaga...@ccppbrasil.org
> >http://groups.google.com/group/dev-guys?hl=en

[Уθя¡ςκ]

Só pra complementar, um addendum contextual:
http://en.wikipedia.org/wiki/Mathematics#Notation.2C_language.2C_and_rigor

[Thiago Adams]

On Jan 18, 2:40 pm, Adriano dos Santos Fernandes <adrian...@gmail.com>
wrote:

Também já tinha feito as "properties" há um tempo.
O que me levou a retomar isso foi o projeto canvas++
(http://code.google.com/p/canvasplusplus/) aonde quero
copiar e colar código java script no C++ e vice versa.
Não quero prender a isso, mas é muito útil na fase de
desenvolvimento e testes aonde comparo o resultado do
meu programa com o mesmo código java script que roda em
um browser.

Esta é a justificativa de aonde e porque estou usando isso.

É interessante compartilhar este estudo que outros já fizeram
e passaram pelos mesmos questionamentos e ver se alguma porta
foi aberta considerando as possibilidades do C++ 11 como auto,
decltype, enable_if, is_convertible etc.

Tudo isso leva a outras perguntas também do tipo:

- Deveria ter esta sintaxe na linguagem? (se fosse criada agora)
- Deveria ser incluído no C++ (considerando 25 anos de gets e sets ?)
- Se já existisse isso no C++ 11, você usaria?
- Aumenta a clareza ou diminui?
- Cria uma nova funcionalidade?


Sobre a questão de clareza, que você diz que não aumenta, acho que
são
dois pontos a serem considerados.

Tem a questão de código mais explicito. Ou seja, aquele codigo que
você
enxerga melhor as operações.
Esconder coisas, deixando o código menos explicito não é novidade no C+
+
visto que existe sobrecarga de operadores. É ruim esconder operações?
É bom que seja tudo explicito? Isso me lembra inclusive a discussão
sobre notação húngara.
Imagine se nós tivéssemos que explicitamente dizer o que é um rvalue
ou lvalue.

rvalue(x) = lvalue(x) + 1;

Isso deixa o código mais explicito, mas é bom? É mais claro?

Quando foram criadas as referencias no C++ muita gente ficou
com medo de código assim:

void f(A&);
f(a);

pois não era possível ver que estava sendo passado "a" como
referencia e não era explicito como o código com ponteiros
f(&a). Pouca gente reclama disso agora.

Além disso, existe a clareza no sentido de código limpo.
Limpeza aumenta clareza, ou seja, se você consegue expressar
um código com menos verbosidade é melhor.

Com isso eu diria que esta sintaxe de propriedade limpa
o código tirando a verbosidade e deixa menos explicito
o que não é necessariamente ruim.

Mas ainda existe outro fator no caso do C++
(parecido com o caso das referencias) que considerando 25
anos de get e sets se isso não iria confundir.

Vou deixar em aberto minha opinião por enquanto, mas o
assunto me ajudou a ver inclusive algumas práticas de
criação classes.

[Ponto V! - Vinícius Godoy]

Eu concordo com o Thiago.
Eu migrei do Java, que tem cultura de gets e sets, para o C#, que é fortemente baseado em propriedades.

Não tem comparação. Algumas operações, como somar 1 numa propriedade ficam:
seuObj.propriedade += 1;

Contra:
seuObj.setPropriedade(seuObj.getPropriedade() + 1);

É claro que se pode argumentar de que seria possível adicionar um método mais simples para fazer essa soma, mas nem sempre esse método existe, e nem sempre você tem controle sobre a classe. Nas propriedades, você acaba de graça com esse tipo de funcionalidade.

Entretanto, acho que se esse recurso não vier sem custo para o programador, ele não compensa. Também já tentei criar um recurso similar em C++, mas fiquei apreensivo com a sintaxe na hora de criar a propriedade, e também com a possibilidade de receber um erro longo de template, por causa de uma operação banal.

[]s,

Vini

--
Antes de enviar um e-mail para o grupo leia:
                    http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
             para Eventos do Grupo C & C++ Brasil:
                       http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~

[&] C & C++ Brasil - http://www.ccppbrasil.org/

Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com

Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

[Rodrigo Madera]

Thiago,

Eu só sei que quando sair a versão "final" da tua lib, eu vou experimentar e ver meu feeling...

Acho que todos deveriamos fazer o mesmo. As vezes pode simplificar bastante o código, vai saber?

Mx

2012/1/19 Ponto V! - Vinícius Godoy <vini...@pontov.com.br>

[Adriano dos Santos Fernandes]

On 19-01-2012 10:48, Ponto V! - Vin�cius Godoy wrote:
> Eu concordo com o Thiago.

> Eu migrei do Java, que tem cultura de gets e sets, para o C#, que �
> fortemente baseado em propriedades.
>
> N�o tem compara��o. Algumas opera��es, como somar 1 numa propriedade ficam:

> seuObj.propriedade += 1;
>
> Contra:
> seuObj.setPropriedade(seuObj.getPropriedade() + 1);
>

Existe outras maneiras tamb�m, como criar um m�todo que retorne uma
refer�ncia (n�o-const) e que vc poderia usar um ++ ou += diretamente.

> ... mas nem sempre esse m�todo existe, e
> nem sempre voc� tem controle sobre a classe.

E as propriedades n�o v�o acabar com esse problema, a menos que vc
obrigue todos a us�-las...

Adriano

[Thiago Adams]

On Jan 19, 11:26 am, Adriano dos Santos Fernandes

<adrian...@gmail.com> wrote:
> On 19-01-2012 10:48, Ponto V! - Vin cius Godoy wrote:
>
> > Eu concordo com o Thiago.
> > Eu migrei do Java, que tem cultura de gets e sets, para o C#, que
> > fortemente baseado em propriedades.
>
> > N o tem compara o. Algumas opera es, como somar 1 numa propriedade ficam:
> > seuObj.propriedade += 1;
>
> > Contra:
> > seuObj.setPropriedade(seuObj.getPropriedade() + 1);
>
> Existe outras maneiras tamb m, como criar um m todo que retorne uma
> refer ncia (n o-const) e que vc poderia usar um ++ ou += diretamente.

Daí perde o sentido de usar propriedade (get set) e basta fazer o dado
publico direto.

[Ponto V! - Vinícius Godoy]

Só para complementar o que o Thiago falou.

No caso que citei, o += 1 ainda chama o setter, exatamente igual se faz em Java.
E no setter pode haver muito código, embora geralmente exista validação.

Esse código, por exemplo, é perfeitamente válido em C#:

namespace TesteCSharp
{
    public class Teste
    {
        private int _propriedade;

        private int Propriedade
        {
            get
            {
                return _propriedade;
            }
            set
            {
                if (_propriedade < 0)
                    throw new ArgumentException("Propriedade não pode ser < 0!");
                _propriedade = value;
            }
        }

        class Program
        {
            static void Main(string[] args)
            {
                Teste t = new Teste();
                t.Propriedade += 1;
            }
        }
    }
}

A cada vez que uma operação matemática é realizada, aquela verificação ali também é realizada, garantindo que a propriedade sempre seja > 0.

[]s,

Vini

[Thiago Adams]

On Jan 19, 11:05 am, Rodrigo Madera <rodrigo.mad...@gmail.com> wrote:
> Thiago,
>
> Eu só sei que quando sair a versão "final" da tua lib, eu vou experimentar
> e ver meu feeling...

A única limitação da implementação via lib que conheço no momento é
quando a propriedade for um objeto e você quiser usar um método deste
objeto.

Por exemplo.

if (x.prop.empty())
{
}

aonde prop aqui é std::string.

O motivo da limitação é que não existe sobrecarga para o operator
ponto.

Existe uma alternativa que é:

if (x.prop().empty())
{
}

http://www.thradams.com/codeblog/properties.htm

[Rodrigo Madera]

Bacana!

Só não esquece de deixar claro tua forma de licença, que impacta quem for usar.

Mx

2012/1/20 Thiago Adams <thiago...@gmail.com>:

[Reuben Morais]

2012/1/20 Thiago Adams <thiago...@gmail.com>:

> A única limitação da implementação via lib que conheço no momento é
> quando a propriedade for um objeto e você quiser usar um método deste
> objeto.
>

Olhando o código rapidamente, vi que você usa offsetof para acessar o
objeto em que a property foi criada.
Se você tentar usar a property da classe pai em uma classe filha com
herança múltipla, isso não deveria explodir?
Até onde eu sei offsetof é indefinido para tipos non-POD.

-- reuben

[Thiago Adams]

On 20 jan, 15:44, Reuben Morais <reuben.mor...@gmail.com> wrote:
> 2012/1/20 Thiago Adams <thiago.ad...@gmail.com>:

>
> > A única limitação da implementação via lib que conheço no momento é
> > quando a propriedade for um objeto e você quiser usar um método deste
> > objeto.
>
> Olhando o código rapidamente, vi que você usa offsetof para acessar o
> objeto em que a property foi criada.

Exatamente. Mas isso não está no centro do design e
poderia ser modificado se necessário.

> Se você tentar usar a property da classe pai em uma classe filha com
> herança múltipla, isso não deveria explodir?

Embora tenha o warning do POD não é fácil achar um caso em que não
funcione. Eu não achei.
Testei em mais um compilador agora o CLANG que vem junto do xcode 4.2.
Até fiquei surpreso
pois não precisei mudar quase nada do código entre VC++ e clang. (Que
maravavilha ter um padrão C++ 11 ! )

> Até onde eu sei offsetof é indefinido para tipos non-POD.

Também vi uma documentação falando isso e também um warning no clang.
Não descobri nenhum caso aonde falhe. Testei alguns casos com herança
e virtuais.

No VC++ , a propria MFC utiliza o offsetof sem impor restrições.
A implementação da STLsoft também usa a offsetof e é multiplataforma.
Ela usa uma versão própria pelo
o que eu vi.