Perguntas sobre Structs

Question

diz MSDN que uma classe que seria 16 bytes ou menos seria melhor tratada como um struct [citação] .
Por que isso?
Isso significa que se um struct é mais de 16 bytes é menos eficiente do que uma classe ou é o mesmo?
Como você determina se sua classe é menos de 16 bytes?
O que restringe a uma estrutura de agir como uma classe? (Além de não permitir construtores sem parâmetros)

Answer 1

Há um par de diferentes respostas para essa pergunta, e é um pouco subjetivo, mas algumas razões que eu posso pensar são:

• Structs são de valor do tipo, as aulas são tipo de referência. Se você estiver usando 16 bytes para armazenamento total, provavelmente não vale a pena para criar referências de memória (4 a 8 bytes) para cada um.
• Quando você tem realmente pequenos objetos, que muitas vezes pode ser empurrado para a pilha IL, em vez de referências aos objetos. Isso pode realmente acelerar algum código, como você está eliminando um dereference memória no lado do receptor.
• Há um pouco de "fluff" extra associado com aulas de IL, e se sua estrutura de dados é muito pequena, nada disso fluff seria usado de qualquer maneira, por isso é apenas lixo extra que você não precisa.

A diferença mais importante entre uma estrutura e uma classe, porém, é que estruturas são do tipo valor e classes são tipo de referência.

Answer 2

Por "eficiente", provavelmente eles estão falando sobre a quantidade de memória que é preciso para representar a classe ou struct.

Na plataforma 32 bits, alocando um objecto exige um mínimo de 16 bytes. Em uma plataforma de 64 bits, o tamanho do objecto mínimo é de 24 bytes. Então, se você está olhando para ele puramente a partir da quantidade de memória usada, uma estrutura que contém menos de 16 bytes de dados será "melhor" do que a classe correspondente.

Mas a quantidade de memória utilizada não é a história toda. tipos de valor (estruturas) são fundamentalmente diferentes de tipos de referência (classes). Structs pode ser inconveniente para trabalhar com, e pode realmente causar problemas de desempenho se você não tiver cuidado.

A verdadeira resposta, claro, é usar o que funciona melhor em sua situação. Na maioria dos casos, você vai ser muito melhor fora de usar classes.

Answer 3

Confira neste link, descobri-lo em uma das respostas em SO hoje: . NET Tipo Internals . Você também pode tentar pesquisar SO e pesquisando por "tipos de referência vs tipos de valor" para as diferenças entre estruturas e classes.

O que restringe a uma estrutura de agir como uma classe?

Existem muitas diferenças. Você não pode herdar de uma estrutura, por exemplo.

Você não pode ter métodos virtuais, para que você não pode usar um struct para implementar uma interface. métodos de instância em structs pode acessar campos privados de struct, mas para além de que eles se comportam muito como funções auxilirary "ajudante" (para estruturas imutáveis, eles às vezes não precisa mesmo de acesso a dados privados). Então, eu acho que eles sejam não tão próximo como "valiosa", como métodos de classe.

Answer 4

Este é devido à maneira diferente que as estruturas alças CLR e classes. Estruturas são tipos de valor o que significa que eles vivem na pilha em vez de no heap gerenciado. É uma boa regra de ouro para manter estruturas pequenas, porque uma vez que você começar a passá-los como argumentos de método você vai incorrer em cima como estruturas são copiados na íntegra quando passado para um método.

Uma vez que as classes passar uma cópia de sua referência a métodos que incorrem muito menos sobrecarga quando usado como argumentos de método.

A melhor maneira de determinar o tamanho da sua classe é para totalizar o número de bytes necessários por todos os membros de sua classe, mais um extra de 8 bytes para o material sobrecarga CLR (o índice de blocos de sincronização e a referência para o tipo de objeto).

Answer 5

Structs são diferentes das aulas porque eles são armazenados na pilha, e não na pilha. Isso significa que cada vez que você chamar um método com a estrutura como parâmetro, uma cópia é criada e passada para o método. É por isso que grandes estruturas são extremamente ineficiente.

Eu iria desencorajar ativamente para usar estruturas no entanto, porque pode causar alguns erros sutis: por exemplo, quando você alterar um campo de um struct, a sua não vai ser refletida para o chamador (porque você mudou apenas a cópia.) - que é um comportamento completamente diferente para as classes

Assim, a 16 bytes eu acho que é um tamanho máximo razoável de um struct, mas ainda assim, na maioria dos casos, é melhor ter uma classe. Se você ainda deseja criar uma estrutura, tentar torná-lo imutável, pelo menos.

Answer 6

Na memória, a estrutura irá armazenar os dados diretamente, enquanto uma classe irá se comportar mais como um ponteiro. Isso por si só faz uma diferença importante, uma vez que passa a estrutura como um parâmetro para um método vai passar seus valores (copiá-los na pilha), enquanto a classe vai passar a referência para os valores. Se a estrutura é grande, você irá copiar uma grande quantidade de valores em cada chamada de método. Quando é realmente pequena copiar os valores e usá-los diretamente será provavelmente mais rápido do que copiar o ponteiro e ter que agarrá-los a partir de outro lugar.

Sobre restrições:. Você não pode atribuí-la a nula (embora você possa usar Nullable <>) e você tem que inicializar-lo imediatamente

Answer 7

Copiar uma instância de um struct leva menos tempo do que criar uma nova instância de uma classe e copiar dados de um velho, mas instâncias de classe podem ser compartilhados e instâncias struct não pode. Assim, "structvar1 = structvar2" requer a cópia nova instância struct, enquanto "classvar1 = classvar2" permite classvar1 e classvar2 referem-se à mesma instância struct (sem ter que criar um novo).

O código para lidar com a criação de novas instâncias de struct é otimizado para tamanhos de até 16 bytes. estruturas maiores são tratados de forma menos eficiente. Estruturas são uma vitória nos casos em que cada variável que contém um struct vai realizar uma instância independente (ou seja, não há nenhuma razão para esperar que quaisquer duas variáveis ??particulares vai realizar instâncias idênticas); eles não são muito de uma vitória (se eles são uma vitória em todos) nos casos em que muitas variáveis ??podem ser a mesma instância.