Structs in C# are fun - Part 8/9: Struct used as default argument values

Leia este post em Português.

Lire cet post en français.

In a previous post we looked at having default parameter values in struct constructors; this time we are going to have a quick look on what happens when we have struct parameters with default values. So, without further ado lets start with the following struct¹:

struct S
{ 
    public int v = 42;
    public S(string s) { v = 13; }
}

and the following usage:

M();

void M(S s = new S()) => Console.WriteLine(s.v);

What you expect the output to be?

If you have been following this post series you probably know that this is a trick question and that neither 42 nor 13 are correct answers since that would require that either the field initializer and/or the constructor to be executed but the expression new S() used as the default parameter value does not implies a constructor invocation (after all there's no such parameterless ctor and if you feel tempted to add one the compiler will happily emit an error since in the presence of such ctor the expression in question does not represent a compile time constant anymore whence it cannot be used as a default parameter value).

When executed that code snippet will output 0 because the compiler simply initializes the full memory used to store the struct instance with zeros (0). By the other hand if you invoke method M() as follows²

M(new S("Foo"));

then the compiler will emit code to execute the constructor and the field initializer and 13 will be printed out, but this has nothing to do with the default parameter value anymore.

And with that we have explored the last not so intuitive struct behavior we intended to cover; next post will be the conclusion of this series.

As always, all feedback is welcome.

Have fun!

---

1. Note that support for field initializers in structs was introduced in C# 10.↩

2. The content of the string is not important in this context. All that matters is that a constructor is invoked.↩

Les structures en C# sont amusantes - Partie 8/9: Structure utilisée comme valeurs d'argument défaut

Leia este post em Português.

Read this post in English.

Dans un article précédent, nous avons examiné l'utilisation de valeurs de paramètres par défaut dans les constructeurs de structures ; cette fois, nous allons examiner rapidement ce qui se passe lorsque nous avons des paramètres de structure avec des valeurs par défaut. Alors, sans plus tarder, commençons par la structure suivante[^1] :

struct S
{
    public int v = 42;
    public S(string s) { v = 13; }
}

et l'utilisation suivante :

M();

void M(S s = new S()) => Console.WriteLine(s.v);

Quelle sortie attendez-vous à obtenir ?

Si vous avez suivi cette série d'articles, vous savez probablement qu'il s'agit d'une question piège et que ni 42 ni 13 ne sont les bonnes réponses, car cela nécessiterait que l' initialiseur de champ et/ou le constructeur soient exécutés, mais l'expression new S() utilisée comme valeur de paramètre par défaut n'implique pas un appel de constructeur (après tout, il n'y a pas de constructeur sans paramètre et si vous êtes tenté d'en ajouter un, le compilateur émettra une erreur car en présence d'un tel constructeur, l'expression en question ne représente plus une constante de compilation, d'où elle ne peut pas être utilisée comme valeur de paramètre par défaut).

Lorsqu'il est exécuté, cet extrait de code affichera 0 car le compilateur initialise simplement la mémoire complète utilisée pour stocker l'instance de structure avec des zéros (0). Par contre, si vous appelez la méthode M() comme suit[^2]

M(new S("Foo"));

dans cette cas le compilateur émettra du code pour exécuter le constructeur et l'initialiseur de champ et 13 sera affiché, mais cela n'a plus rien à voir avec la valeur de paramètre par défaut.

Et avec cela, nous avons exploré le dernier comportement de structure pas si intuitif que nous avions l'intention de couvrir ; le prochain article sera la conclusion de cette série.

Comme toujours, tous les commentaires sont les bienvenus.

Amusez-vous bien !

---

[^1] : Notez que la prise en charge des initialiseurs de champs dans les structures a été introduite dans C# 10.

[^2] : Le contenu de la chaîne n'est pas important dans ce contexte. Tout ce qui compte, c'est qu'un constructeur est appelé.

Structs em C# - diversão garantida - Parte 8/9: Struct usada como valores padrão para argumentos

Read this post in English.

Lire cet article en français.

Em um post anterior examinamos o uso de parâmetros com valores default em construtores de structs; desta vez, vamos dar uma olhada rápida no que acontece quando temos parâmetros do tipo struct com valores default. Então, sem mais delongas, vamos começar com a seguinte struct¹:

struct S
{
    public int v = 42;
    public S(string s) { v = 13; }
}

e o seguinte uso:

M();

void M(S s = new S()) => Console.WriteLine(s.v);

Qual saída você espera obter?

Se você tem acompanhado esta série de posts provavelmente notou que esta é uma pergunta capciosa e que nem 42 nem 13 são respostas corretas uma vez que para que tais valores pudessem ser impressos isso exigiria que o inicializador de campo e/ou o construtor fossem executados, mas a expressão new S() usada como valor default em parâmetros não implica uma invocação de construtor (afinal, não há um construtor sem parâmetros e, caso você esteja tentado a adicionar um, o compilador emitirá um erro, pois, na presença de tal construtor, a expressão em questão não representa mais uma constante de tempo de compilação, portanto, não pode ser usada como um valor default).

Na realidade, quando executado o trecho de código exibirá 0 pois o compilador simplesmente inicializa a memória usada para armazenar a instância da struct com zeros (0). Por outro lado, se você invocar o método M() como a seguir²:

M(new S("Foo"));

o compilador emitirá código para executar o construtor e o inicializador de campo e 13 será impresso, mas isso não tem mais nada a ver com o valor de parâmetro padrão.

E com isso exploramos o último comportamento não tão intuitivo de estruturas que pretendíamos abordar; o próximo post será a conclusão desta série.

Como sempre, todos os comentários são bem-vindos.

Divirta-se!

---

1. Observe que o suporte para inicializadores de campo em structs foi introduzido no C# 10.↩

2. O conteúdo da string não é importante neste contexto. Tudo o que importa é que um construtor seja invocado.↩

Structs em C# - diversão garantida - Parte 7/9: A funcionalidade *required members* do C# 11 não vai salvar seu emprego

Lire cet post en français.

Read this post in English

A história deste post é um pouco embaraçosa.

Durante o processo de definição dos tópicos que eu cobriria, aprendi sobre uma funcionalidade do C# 11 chamada required members que, ingenuamente, pensei poderia ser usada para sinalizar esses cenários, então planejei adicionar um post mostrando como alcançar isso; no entanto, durante a investigação/redação¹ do conteúdo percebi que esse não era um dos objetivos dessa funcionalidade e que havia vários casos extremos em que nenhum aviso seria emitido, mesmo que nenhum construtor fosse invocado².

A ideia principal era marcar todos os membros (campos/propriedades) que seriam inicializados nos construtores como required e adicionar o atributo SetsRequiredMembers a esses construtores, de forma que, nos casos em que nenhum construtor (decorado com SetRequiredMembersAttribute) fosse invocado, o compilador emitiria um aviso/erro devido à não inicialização desses membros.

Essa técnica funciona relativamente bem se quisermos capturar um cenário muito problemático: a instanciação de tipos de valor com um construtor em que todos os seus parâmetros possuim valores opcionais³. Para tornar a discussão mais concreta, vamos pegar nosso último exemplo do post anterior e modificá-lo conforme descrito acima:

Print(new S2());
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public required int v;
    
    [System.Diagnostics.CodeAnalysis.SetsRequiredMembers]
    public S2(int i = 42)  => v = i;
}

Com essa mudança em vez de obter silenciosamente uma instância de S2 inicializada com zero (em oposição ao esperado 42 se o construtor fosse invocado), o compiladore emite o seguinte erro:

error CS9035: O membro obrigatório 'S2.v' deve ser definido no inicializador de objeto ou no construtor de atributo.

Não é perfeito, já que a mensagem provavelmente será muito confusa se alguém estiver (incorretamente, mas compreensivelmente) esperando que o construtor de S2 seja invocado, mas há outras limitações que tornam essa abordagem ainda menos viável:

• Incapacidade de detectar construtores não invocados (pelo menos) em expressões default e instanciações de arrays.
• Mesmo em cenários em que isso funcionaria, é impossível garantir que um construtor será invocado (por exemplo, se mudarmos o código na linha #1 para new S2() { v = 5 }, nenhum construtor será invocado, mas nenhum aviso/erro será emitido)

Uma alternativa mais eficaz (se você implantar sua aplicação como gerenciada em vez de compilá-la AOT) para detectar tais cenários é garantir explicitamente que instâncias de struct foram inicializadas⁴ (seja por um construtor ou por outros meios) antes de acessar seus membros; como o código está gerado em tempo de execução pelo JIT, é possível implementar isso de forma que os usuários possam controlar se tal verificação deve ser aplicada ou com muito pouco (ou nenhum) impacto em desempenho quando a verificação está desativada, como demonstrado abaixo.

using System.Runtime.CompilerServices;

class Driver
{
    static void Main()
    {

        for(int i = 0; i < 100_000; i++)
        {
            var foo = new Foo(); // Nenhum construtor invocado... nenhum aviso :(
            Thread.Sleep(100);
            foo.Use();
        }
    }

}

// A estrutura pode ser declarada em um assembly diferente também. 
struct Foo
{
    // é importante que o campo seja marcado como `readonly`
    private static readonly bool _shouldValidate = Environment.GetEnvironmentVariable("VALIDATE_FOO") == "true";

    private int _i;
    private bool _isInitialized;

    public Foo(int v = 1) { _i = v; _isInitialized = true; }

    public void Use()
    {
        Verify();
        System.Console.WriteLine(_i);
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)] // É importante pedir que o JIT inline este método para que a otimização seja aplicada.
    private readonly void Verify()
    {
        if (_shouldValidate)
        {
            if (!_isInitialized)
            {
                throw new Exception("O construtor de Foo não foi invocado; isso pode ser devido a uma declaração de array ou ...");
            }
        }
    }
}

O código usa o campo _shouldValidate para controlar se a verificação de inicialização⁴ deve ser aplicada ou não (neste caso, mais especificamente, se o construtor foi executado). Observe que o mesmo é declarado como static readonly; isso é muito importante pois assim o JIT sabe que, uma vez inicializada uma dada instância de struct, o valor do campo nunca mudará, podendo tratar _shouldValidate como uma constante não gerando código para verificá-lo no if na linha #XX; além disso, caso esta constante seja avaliada como false, o JIT pode remover o if (incluindo seu corpo) completamente (daí o custo quase zero mencionado anteriormente).

Você pode ver essa mágica do JIT em ação abrindo um terminal, criando uma aplicação de console com o código acima e executando:

DOTNET_JitDisasm=Use dotnet run -c Release

o qual:

1. em sistemas operacionais do tipo unix, define a variável de ambiente DOTNET_JitDisasm como Use, o que instrui o JIT a fazer o dump do código assembly gerado para o método de mesmo nome.
2. compila a aplicação em modo release (-c Release), o que é um requisito para que a otimização seja aplicada.
3. executa a aplicação.

Ao executar DOTNET_JitDisasm=Use dotnet run -c Release, você deve ver zeros (0) e algum código assembly sendo impresso no terminal várias vezes; após algumas iterações, você deve ser capaz de identificar código assembly semelhante ao abaixo (certifique-se de verificar o que mesmo contém Tier1 em vez de Tier0):

; Assembly listing for method Foo:Use():this (Tier1)
; Emitting BLENDED_CODE for X64 with AVX - Unix
; Tier1 code
; optimized code
; rsp based frame
; fully interruptible
; No PGO data
; 1 inlinees with PGO data; 0 single block inlinees; 0 inlinees without PGO data

G_M000_IG01:                ;; offset=0x0000
 
G_M000_IG02:                ;; offset=0x0000
       mov      edi, dword ptr [rdi]
 
G_M000_IG03:                ;; offset=0x0002
       tail.jmp [System.Console:WriteLine(int)]
 
; Total bytes of code 8

que basicamente chama System.Console.WriteLine(_i) e retorna, sem nenhum traço da invocação do método Verify().

Você também pode brincar com este exemplo executando-o como:

DOTNET_JitDisasm=Use VALIDATE_FOO=true dotnet run -c Release

nesse caso, ele lançará uma exceção (provando que o uso de instâncias de struct não inicializadas é detectado)

ou

DOTNET_JitDisasm=Use dotnet run -c Debug

não importando nesse caso quanto tempo a aplicação seja executada, o código assembly gerado para Use() sempre chamará Verify() (ou seja, a otimização não foi aplicada porque a aplicação foi compilada em modo debug)

Com essa abordagem, pode-se ter certeza de que nenhum código está usando instâncias não inicializadas simplesmente executando o código com a variável de ambiente definida como true e observando exceções.

Como sempre, todos os feedbacks são bem-vindos.

Divirta-se!

---

1. aqui você pode encontrar alguns códigos de teste que usei enquanto explorava este tópico.↩

2. Depois de perceber isso, mudei o título do post :).↩

3. Este caso específico é problemático devido à expectativa de que o comportamento corresponderia ao comportamento para classes.↩

4. Nota de esclarecimento: Do ponto de vista da runtime, structs são garantidas de serem inicializados (zerando toda a struct) antes de serem usadas. Inicialização no contexto desta série significa que todos os campos/propriedades da struct foram atribuídos valores significativos, deixando a instância em um estado consistente.↩↩

Structs in C# are fun - Part 7/9: Required feature from C# 11 will not save your a** job.

Leia este post em Português.

Lire cet post en français.

The history of the current post is a little bit embarrassing.

During the process of defining the topics I'd cover I've learned about a C# 11 feature called required members which I naively though could be used to flag these scenarios so I planned to add a post showing how to achieve that; however during investigation/drafting¹ the content, I've realized that that was not one of the goals of this feature and that there were multiple corner cases in which no warning would be emitted even though no constructor would be invoked².

The main idea would be to to mark all members (field/properties) that would be initialized in the constructors as required and add the SetsRequiredMembers attribute to these constructors in such a way that in cases where no constructors (decorated with SetRequiredMembersAttribute) were to be invoked the compiler would emit a warning/error due to the non-initialization of such members.

This technique works relatively well if one wants to catch a very problematic scenario: instantiation of value types with a constructor in which all of its parameters are optional³. To make the discussion more concrete, lets take our last example from the previous post and modify it as described above:

Print(new S2());
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public required int v;
    
    [System.Diagnostics.CodeAnalysis.SetsRequiredMembers]
    public S2(int i = 42)  => v = i;
}

With this change in place, instead of silently getting an instance of S2 initialized with zero (as opposed to the expected 42 if the constructor were to be invoked), we get the following error:

error CS9035: Required member 'S2.v' must be set in the object initializer or attribute constructor.

Not perfect, given that the message will probably be very confusing if one is (incorrectly, but understandably) expecting S2 constructor to be invoked, but there are other limitations rendering this approach even less viable:

• Inability to detect constructors not being invoked (at least) in default expression and array instantiations.
• Even in scenarios in which this would work it is impossible to guarantee that a ctor will be invoked (for instance, if we change the code at line #1 to new S2() { v = 5 }, no constructor will be invoked but no warning/error will be emitted either)

A more effective alternative (if you deploy your application as a managed one as opposed to AOTing it) to detect such scenarios is by explicitly asserting that struct instances have been initialized⁴ (either by a constructor or some other means) prior to accessing its members; since the code is being JITed one can implement this in a way users can control whether the check should be enforced or not and have very little (if any) performance impact when enforcing is disabled, as demonstrated below.

using System.Runtime.CompilerServices;

class Driver
{
    static void Main()
    {

        for(int i = 0; i < 100_000; i++)
        {
            var foo = new Foo(); // No constructor invoked... no warnings :(
            Thread.Sleep(100);
            foo.Use();
        }
    }

}

// The struct can be declared in a different assembly also. 
struct Foo
{
    // it is important for the field to be marked as `readonly`
    private static readonly bool _shouldValidate = Environment.GetEnvironmentVariable("VALIDATE_FOO") == "true";

    private int _i;
    private bool _isInitialized;

    public Foo(int v = 1) { _i = v; _isInitialized = true; }

    public void Use()
    {
        Verify();
        System.Console.WriteLine(_i);
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)] // It is important to ask the JIT to inline this method for the optimization to be applied.
    private readonly void Verify()
    {
        if (_shouldValidate)
        {
            if (!_isInitialized)
            {
                throw new Exception("Foo constructor was not invoked; this may be due an array declaration or ...");
            }
        }
    }
}

The code use the field _shouldValidate to control whether correct initialization⁴ should be enforced or not (in this case more specifically, if the constructor has been executed). Notice that this field is declared as static readonly; this is very important since with this in place the JIT knowns that, for a given struct instance, once initialized, the field value will never change so it is free to handle _shouldValidate as a constant and to not generate code to check it in the if in line #XX; moreover, in case it is evaluated to false the JIT can remove the whole if statement (whence the close to zero overhead mentioned before).

You can see this JIT magic in action by opening a terminal, creating a console application with the code above and running:

DOTNET_JitDisasm=Use dotnet run -c Release

which:

1. in unix like OSs, sets the environment variable DOTNET_JitDisasm value to Use and runs dotnet run -c Release.
2. builds the application in release mode (-c Release), which is requirement for the optimization to be applied.
3. instructs the JIT to dump the JITed assembly code for the method Use() by setting DOTNET_JitDisasm environment variable accordingly.

When executing that command line you should see zeros (0) and some assembly code being printed to the terminal multiple times; after some iterations you should be able to spot some assembly code resembling the one below (make sure to check the one that contains Tier1 as opposed to Tier0):

; Assembly listing for method Foo:Use():this (Tier1)
; Emitting BLENDED_CODE for X64 with AVX - Unix
; Tier1 code
; optimized code
; rsp based frame
; fully interruptible
; No PGO data
; 1 inlinees with PGO data; 0 single block inlinees; 0 inlinees without PGO data

G_M000_IG01:                ;; offset=0x0000
 
G_M000_IG02:                ;; offset=0x0000
       mov      edi, dword ptr [rdi]
 
G_M000_IG03:                ;; offset=0x0002
       tail.jmp [System.Console:WriteLine(int)]
 
; Total bytes of code 8

which is basically calling System.Console.WriteLine(_i) and returning, with no traces of the method Verify() invocation.

You can also play around with this example by running it as:

DOTNET_JitDisasm=Use VALIDATE_FOO=true dotnet run -c Release

in which case it will throw an exception (proving that uninitialized struct instances usage is detected)

or

DOTNET_JitDisasm=Use dotnet run -c Debug

in which case, no matter for how long the application runs, the assembly code generated for Use() will always call Verify() (i.e. optimization was not applied because application was built in debug mode)

With this approach one can be sure that no code is using uninitialized instances by simply running the code with the environment variable set to true and observing for exceptions.

As always, all feedback is welcome.

Have fun!

---

1. here you can find some test code I used while exploring this topic.↩

2. After realizing that I've changed the post's title :).↩

3. This particular case is problematic due to the expectation that the behavior would match the behavior for classes↩

4. Note of clarification: From the perspective of the runtime, structs are guaranteed to be initialized (by zeroing out the whole struct) before being used. Initialization in the context of this series of posts means that all struct fields/properties have been assigned meaningful values leaving the instance in a consistent state.↩↩

Les structures en C# sont amusantes - Partie 6/9: Struct avec des valeurs d'argument par défaut dans les constructeurs, ou, n'êtes-vous pas encore confus ?

Leia este post em Português

Read this post in english

1. Les structures en C# sont amusantes
2. Brève introduction aux Value Types vs Reference Types.
3. Initialisation des champs dans les structures.
4. Comportement des constructeurs dans structures.
5. Des autres scénarios dans lesquels le comportement des constructeurs de structure peut vous surprendre.
6. Struct avec des valeurs d'argument par défaut dans les constructeurs, ou, n'êtes-vous pas encore confus ? (cet post)
7. Le modificateur required de C # 11 ne sauvegardera pas votre c*l emploi.
8. Structure utilisée comme valeurs d'argument défaut.
9. Bonus: L'evolution des structures en C#.

Dans les derniere posts, nous avons vu que le compilateur C# peut net pas exécuter le constructeur des structs dans certains scénarios. Malheureusement, l'expérience avec les constructeurs dans les structures, du moins à mon avis, peut devenir encore plus déroutante.

Pour illustrer mon point, supposons que vous ayez le code suivant :

Print(new S2()); 
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public int v;
    public S2(int i = 42)  => v = i;
    public S2() => v = 84;
}

Quel résultat attendez-vous s’il est compilé/exécuté¹ ?

1. Le compilateur émettra une erreur en affirmant que new S2() est un appel ambigu.
2. Il compile et génère 42, 13.
3. Il compile et génère 84, 13.

La bonne réponse, qui peut surprendre certains développeurs, est qu'il se compile avec succès et affiche 84 et 13 (c'est-à-dire la troisième option).

Cela se produit parce qu'à la ligne 1, le compilateur C# considère le constructeur sans paramètre comme une meilleure correspondance (better match) que celui avec la valeur de paramètre par défaut excluant les options 1 et 2¹. Le bon côté est que même si cela n'est pas totalement évident, au moins ce comportement est cohérent entre les classes/structures.

Pourtant, avec les structures, cela peut devenir encore plus complexe/déroutant ; imaginez que vous avez exactement le même code que ci-dessus, la seule différence étant la suppression du constructeur sans paramètre :

Print(new S2()); 
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public int v;
    public S2(int i = 42)  => v = i;
}

maintenant, c'est sûr qu'il imprimera 42, 13, n'est-ce pas ?

Non! Dans ce scénario, contrairement aux classes, un constructeur avec des valeurs par défaut pour tous ses paramètres n'est pas invoqué, même sur une new expression explicite², ce qui signifie que le code ci-dessus imprimera 0 et 13³.

Dans le prochain article, nous examinerons rapidement les membres requis C# 11⁴ comme moyen d'aider à identifier les scénarios dans lesquels aucun constructeur n'est invoqué.

Comme toujours, tous les commentaires sont les bienvenus.

Amusez-vous!

---

1. Pour être honnête, le comportement ici est le même pour les classes, donc au moins il est cohérent.↩↩

2. la spécification des constructeurs sans paramètre dans les structures indique explicitement que ce comportement est le même que dans les versions précédentes de C#.↩

3. Cela se produit parce que la ligne n°1 est équivalente à Print(default(S2)) ; pour plus de détails, voir cet article.↩

4. Je suis conscient que ce n'est pas l'utilisation prévue de cette fonctionnalité, mais elle peut être utilisée pour signaler quelques instanciations de structure qui n'invoquent pas de constructeur.↩

Structs in C# are fun - Part 6/9: Struct with default argument values in ctors a.k.a, are you not confused yet ?

Leia este post em Português

Lire cet post en français.

In the previous post we saw that the C# compiler may not emit a ctor invocation in some scenarios. Unfortunately the experience with constructors in structs, at least in my opinion, may get even more confusing.

To illustrate this point, suppose you have the following code:

Print(new S2()); 
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public int v;
    public S2(int i = 42)  => v = i;
    public S2() => v = 84;
}

What do you expect to happen when you compile/run this code¹?

1. Compiler will emit an error claiming new S2() is an ambiguous call.
2. It compiles and outputs 42, 13.
3. It compiles and outputs 84, 13.

The correct answer, which may surprise some developers, is that it compiles successfully and prints 84 and 13 (i.e, the third option).

That happens because in line 1 the C# compiler sees the parameterless constructor as a better match than the one with the default parameter value ruling out options 1 and 2¹. The bright side is that even not being totally obvious, at least this behavior is consistent across classes/structs,

However, with structs, it may get even more complex/confusing; imagine you have exactly the same code as above, with the only difference being the removal of the parameterless constructor:

Print(new S2()); 
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public int v;
    public S2(int i = 42)  => v = i;
}

now, for sure it will print 42, 13, right ?

Nope! In this scenario, differently from classes, a constructor with default values for all of its parameters is not invoked, even on an explicit new expressions² which means the code above will print 0 and 13³.

In the next post we'll take a quick look into required members C# 11 feature⁴ as a way to help pin-pointing scenarios in which no constructor is being invoked.

As always, all feedback is welcome.

Have fun!

---

1. To be fair the behavior here is the same for classes, so at least it is consistent↩↩

2. The specification of parameterless constructors in structs explicitly states that this behavior is the same as in previous versions of C#↩

3. That happens because line #1 is equivalent to Print(default(S2)); for more details see this post.↩

4. I am aware that this is not the intended use of this feature but it may be used to flag struct instantiations that does not invoke a constructor.↩

Structs em C# - diversão garantida - Parte 6/9: Argumentos default em construtores de estruturas (você ainda não esta confuso ?)

Lire cet post en français.

Read this post in english

1. Structs em C# - diversão garantida
2. Rápida introdução à Value Types vs Reference Types
3. Inicialização de campos em estruturas
4. Comportamento de construtores em estruturas.
5. Outros cenários em que o comportamento de construtores em estruturas podem te surpreender.
6. Argumentos default em construtores de estruturas (você ainda não esta confuso ?). (este post)
7. Modificador required do C# 11 não vai salvar seu c* trabalho.
8. Estruturas usadas como valor default de argumentos.
9. Bonus: Evolução das estruturas em C#.

Nos posts anteriores vimos que, em alguns cenários, o compilador C# pode não emitir invocaçcões de construtores de estruturas. Infelizmente a experiência com construtores em structs, pelo menos na minha opinião, pode ficar ainda mais confusa.

Para ilustrar esse ponto, suponha que você tenha o seguinte código:

Print(new S2()); 
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public int v;
    public S2(int i = 42)  => v = i;
    public S2() => v = 84;
}

Qual resultado você espera observar ao compilar/executar o mesmo? ¹

1. O compilador emitirá um erro informando que new S2() representa uma chamada ambígua.
2. Ele compila e gera 42, 13.
3. Ele compila e gera 84, 13.

A resposta correta, que pode surpreender alguns desenvolvedores, é que o programa compila com sucesso e imprime 84 e 13 (ou seja, a terceira opção).

Isso acontece porque na linha 1 o compilador C# vê o construtor sem parâmetros como uma melhor correspondência (best match) que aquele com o valor do parâmetro default, descartando as opções 1 e 2¹. O lado bom é que mesmo não sendo totalmente óbvio, pelo menos este comportamento é consistente entre classes/estruturas,

No entanto, o comportamento de construtores com relação à estruturas pode ficar ainda mais complexo/confuso; imagine que você tem exatamente o mesmo código acima, com a única diferença sendo a remoção do construtor sem parâmetros:

Print(new S2()); 
Print(new S2(13));

void Print(S2 s) => System.Console.WriteLine(s.v);

struct S2
{ 
    public int v;
    public S2(int i = 42)  => v = i;
}

agora, com certeza o mesmo vai imprimir 42 e 13, certo?

Não! Neste cenário, diferentemente das classes, um construtor com valores padrão para todos os seus parâmetros não é invocado, mesmo em expressões new explícitas² o que significa que o código acima irá imprimir 0 e 13³.

Na próxima postagem, daremos uma olhada rápida em uma funcionalide do C# 11 conhecida como required members⁴ como uma forma de ajudar a identificar cenários nos quais nenhum construtor é invocado.

Como sempre, todo feedback é bem-vindo.

Divirta-se!

---

1. Para ser justo, o comportamento aqui é consistente com o de classes.↩↩

2. A especificação de construtores sem parâmetros em estruturas afirma explicitamente que esse comportamento é o mesmo das versões anteriores do C#.↩

3. Isso acontece porque a linha #1 é equivalente a Print(default(S2)); para obter mais detalhes, consulte esta postagem.↩

4. Estou ciente de que este não é o uso pretendido deste recurso, contudo o mesmo pode ser usado para sinalizar algumas instanciações de estruturas que não invocam um construtor.↩

Structs em C# - diversão garantida - Parte 2/9: Uma breve introdução a Value types versus Reference types

Read this post in English.

Lisez cet post en french.

1. Structs em C# - diversão garantida
   
2. Rápida introdução à Value Types vs Reference Types (este post).
3.  Initialização de campos em estruturas.
4.  Comportamento de construtores em estruturas.
5.  Outros cenários em que o comportamento de construtores em estruturas podem te surpreender.
6.  Argumentos default  em construtores de estruturas (você ainda não esta confuso ?).
7.  Modificador `required` do C# 11 não vai salvar seu c* trabalho.
8.  Estruturas usadas como valor default de argumentos.
9.  Bonus: Evolução das estruturas em C#. 
   

Desde o lançamento oficial da primeira versão do C# (versão 1.0, em janeiro/2002),  desenvolvedores se deparam com uma decisão ao introduzir novos tipos: declará-los como class (Reference Type) ou struct (Value Type), representados no .NET por System.Object e System.ValueType respectivamente.

Escolher um ou o outro tem implicações não triviais com relação à usabilidade, desempenho e extensibilidade, para listar alguns. Neste post, quero cobrir brevemente as principais diferenças (mais detalhes serão apresentados nos posts futuros se necessário) e esclarecer uma concepção equivocada (a qual provavelmente sou culpado por contribuir para sua disseminassão). Então, sem mais delongas, vamos entrar na distinção mais importante sobre os dois...

Semântia de referencia versus de valor

A característica mais importante que distingue esses 2 tipos está relacionada a como a igualdade e a atribuição/passagem de parâmetro são tratadas. A tabela abaixo mostra essas diferenças (supondo que os tipos em questão não sobrecarreguem o método Equals() ou os operadores ==/!=):

	Value Type	Reference Type
Assignment semantics	por valor, ou seja, o conteúdo da instância é copiado resultando em duas cópias independentes.	por referência, ou seja, a atribuição apenas copia uma referência e  mudanças através de qualquer uma das referências serão observadas ao acessar o objeto através da outra.
Equality (Identity semantics)	duas instâncias são iguais se forem instâncias do mesmo tipo e todos os seus campos forem iguais.	duas instâncias são iguais se referênciarem o mesmo objeto.

Para facilitar a visualização, imagine o seguinte código:

Durante sua execução, ao chegar na linha 15, podemos representar, de uma forma  simplificada, a memória utilizada para o armazenamento das variáveis v1 e v3 como algo:

ou seja, as variávis v1 e v3 são armazenadas nos endereços 0x100 e 0x400 respectivamente. Observe contudo que a variável v3 não armazena o contéudo da instância do objeto AReferenceType mas sim uma referência (ou, novamente em uma simplificação, um ponteiro) para o objeto instanciado no endereço 0x1000. v1 (uma instância da estrutura  AValueType) por sua vez armazena os dados da instância diretamente (sem indireções).

Se inspecionarmos o estado da memória quando o programa executa a linha 19 observaremos algo como:

Observe que ambas as variáveis (v1 & v3) tem seus conteúdos copiados para as variáceis recem declaradas (v2 & v4) mas como v3 é uma refeence type, copiar seu valor implica copiar a referência (endereço) armazenada na mesma, fato que ficará mais evidente a frente.

Desta forma, ao imprimir os campos IntValue de v1 & v2 o mesmo resultado é produzido; contudo,  após armazenar o valor 71 em v2.IntValue (linha 21) o estado da memória pode ser representado como:

e consequentemente a linha 22 do programa imprimirá os valores 42 & 71 evidenciando que v1 & v2 são independentes um do outro.

Reference types funcionam de uma forma diferente; ao executar a instrução na linha 25 o valor do campo IntValue das variáveis v3 e v4 são impressos. Para determinar quais valores serão passados para o método Console.WriteLine(), primeiramente o valor de v3 (0x1000) é lido da possição de memória 0x400 (v3) e a seguir, o conteúdo desta posição (0x1000) (ou mais precisamente 4 bytes que compõem um int em C#) é lido, resultando no valor 42; a seguir o memo processo é repetido para a variável v4 e como esta referencia o mesmo objeto que v3 (0x1000) o mesmo resultado é prodizido.

Uma vez que um processo similar é aplicado ao se modificar o conteúdo de um Reference Type, após a execução da linha 26 o estado da memória se parecerá com

 

e a linha 27 imprimirá 71 & 71, ou seja, modificações aplicadas ao objeto referenciado por v4 são observadas através da variável v3 (o que faz todo o sentido já que ambas variáveis referenciam o mesmo objeto).

Concepções equivocadas

Ao longo dos anos, li vários artigos, entrevistas e até alguns livros afirmando que uma das principais diferenças entre Reference Types e Value Types é que Value Types são sempre armazenados na pilha, enquanto Reference Types são sempre armazenados no heap.

Esse equívoco é tão difundido que Eric Lippert (o qual trabalhou como um dos designers de C# no passado) escreveu 2 postagens de blog com o objetivo de  acabar com a confusão.

Como Eric menciona, o fato de Value Type serem normalmente alocados na pilha é um detalhe de implementação. Contudo, na minha opnião este é um detalhe que dificilmente mudará uma vez que esse comportamento é essencial em cenários em que manter baixas as alocações de heap (e, consequentemente, a pressão de GC) é crucial.

Como sempre, todo feedback é bem-vindo.

Have fun!

Structs em C# - diversão garantida - Parte 1/9

Lisez cet post en french.

Read this post in English.

Mesmo existindo desde a introdução de .NET, Value types (e consequentemente, structs) possuem vários aspectos que ainda em 2023 são uma fonte de confusão (pelo menos para mim). Assim sendo decide fazer uma lista dos comportamentos que podem não ser tão óbvios, os quais abordarei em na série de futuro posts abaixo:

1. Este post.
   
2. Rápida introdução à Value Types vs Reference Types.
3. Initialização de campos em estruturas.
   
4. Comportamento de construtores em estruturas.
   
5. Outros cenários em que o comportamento de construtores em estruturas podem te surpreender.
6. Argumentos default  em construtores de estruturas (você ainda não esta confuso ?).
7. Modificador `required` do C# 11 não vai salvar seu c* trabalho.
   
8. Estruturas usadas como valor default de argumentos.
9. Bonus: Evolução das estruturas em C#.

atualizando os links acima na medida que postar sobre cada assunto.

Antes de continuar, observe que esta série reflete o estado corrente do C#, ou seja,  a versão 11 (.NET 7.0).

Espero que a mesma possa ajudá-lo, mesmo se você for um desenvolvedor  C# experiente.

Como de praxe, todo retorno é bem vindo.

Have fun!

Structs in C# are fun - Part 1/9

Leia este post em português

Lisez cet post en french.

Value types (and consequently, structs) existed in .NET since its inception, yet they are still a source of confusion in 2023 (at least for me). So I decided to collect a list of subjects, that may or may not be so obvious to some .NET developers, and I'll discuss them in the following posts (I'll update the list adding links as I post about each topic):

1. This post.
   
2. Brief introduction to Value Types vs Reference Types.
3. Field initialization in structs.
4. Constructors and struct behavior.
5. Other scenarios in which struct constructors behavior may surprise you.
6. Struct with default argument values in constructors, a.k.a, are you not confused yet ?
7. `required` feature from C# 11 will not save your a** job.
   
8. Struct used as default argument values.
9. Bonus: Struct evolution in C#.
   

Before continuing, note that this series reflects the current state of C# as of version 11 (.NET 7.0).

Last, but not least, even if you are an experienced C# developer I hope you can learn something or, why not, add your own perspective/contribution to the subject.

As always, all feedback is welcome.

Have fun!

Les structures en C# sont amusantes - Partie 1/9

Leia este post em português

Read this post in English.

Les value types (et par conséquent, les structures) existaient dans .NET depuis sa création, mais ils sont toujours une source de confusion en 2023 (au moins pour moi). J'ai donc décidé de rassembler une liste de comportements, qui peuvent ne pas être si évidents pour certains développeurs .NET, laquelle j'en discuterai dans le série de futurs articles ci-dessous:

1. Ce post.
   
2. Brève introduction aux Value Types vs Reference Types.
3. Initialisation des champs dans les structures.
4. Comportement des constructeurs dans structures.
5. Des autres scénarios dans lesquels le comportement des constructeurs de structure peut vous surprendre.
6. Struct avec des valeurs d'argument par défaut dans les constructeurs, ou, n'êtes-vous pas encore confus ?
7. Le modificateur `required`de C # 11 ne sauvegardera pas votre c*l emploi.
   
8. Structure utilisée comme valeurs d'argument défaut.
9. Bonus: L'evolution des structures en C#.
   

Avant de continuer, svp, notez que cette série reflète l'état actuel de C#, cet a dire, la version 11 (.NET 7.0).

Même si vous êtes un développeur C# expérimenté, j'espère que vous pourrez apprendre quelque chose ou, pourquoi pas, ajouter votre point de vue/contribution au sujet..

Comme toujours, tous les commentaires sont bienvenus.

Amusez-vous!

Fun with references in C# - Part I / II

Leia este post em português

Lire cet post en Français.

I'll begin 2023 (late February :)) posts with a quick puzzle about C#.

Given the program below answer the following questions:

1. What is its output ?

2. Can you spot/explain the issues in the code?

3. How could one pinpoint the issue?

Of course you are free to compile/run it, and I do encourage you to do so, but I do suggest to only do it after you have formulated an hypothesis or if only inspecting the code does not ring any bells.

See you in the next post.

Have fun!

Adriano

Amusement avec les références en C# - Partie I / II

Leia este post em português

Read this post in English.

Je commencerai les messages de 2023 (fin février :)) avec une petite casse-tête sur C#.

Compte tenu du programme ci-dessous, répondez aux questions suivantes:

1. Quelle est sa sortie ?

2. Pouvez-vous repérer/expliquer les problèmes dans le code ?

3. Comment identifier le problème ?

Bien sûr, vous êtes libre de le compiler/l'exécuter, et je vous encourage à le faire, mais je suggère de ne le faire qu'après avoir formulé une hypothèse ou si seulement inspecter le code ne vous dit rien. 

A bientôt

Amusez-vous!

Adriano

Diversão com referências em C# - Parte I / II

Read this post in English.

Lire cet post en Français.

Vou começar os posts de 2023 (no final de Fevereiro :)) com um pequeno quebra-cabeças em C#.

Dado o programa abaixo, responda as seguintes questões:

1. O que será impresso?

2. Você é capaz de apontar/explicar os problemas no mesmo?

3. Como poderíamos notar o problema apenas fazendo inspeção do código?

Claro que você pode compilar/rodar o programa (inclusive eu recomendo que você o faça), contudo seria interessante criar uma hipotese antes.

Até o próximo post.

Divirta se!

Adriano

Um pequeno puzzle sobre o C# 10

Lire cet post en Français.

Read this post in English.

Você desenvolve em C# no seu dia a dia? Tem acompanhado os últimos avanços desta linguagem, mais especificamente na versão 10? Gosta de desafios de programação ? 

Caso a resposta a uma ou mais das perguntas acima seja sim, você conseguiria, mudando apenas o tipo do parâmetro msg do método Foo(), fazer com que a saída do programa contenha apenas as linhas com números pares?

ou seja, fazer com que a saída do programa seja:

ao invés de:

As regras são:

1. A única modificação válida no método Foo() é alterar o tipo do parâmetro msg.
2. Você não pode modificar o corpo do programa, principalmente o laço for.
3. Você não pode utilizar nenhuma técnica de IL post-processing.
4. Qualquer outra alteração no código fonte é válida.
   

Seguem algumas considerações:

1. A solução para o problema proposto envolve um recurso que foi aprimorado na versão 10 da linguagem.
   
2. Observe bem o código acima; procure por elementos não essenciais; estes elementos contém pistas que podem ajudar.

Nos próximos posts eu vou apresentar e discutir a minha solução.

Divirta-se.

Adriano