Bugs?

Vita da service pack

Adrian Florea — Thu, 26 Mar 2009 12:40:42 GMT

Ho scoperto una cosa a mio parere strana: un metodo (System.Web.UI.WebControls.ParameterCollection.Add(String, DbType, String)) che esiste solo nelle versioni service pack del framework .NET (2.0 SP2, 3.0 SP2, 3.5 SP1) ma non nelle versioni "normali". Mi chiedo come mai se il metodo e' stato introdotto in .NET 2.0 SP2, l'abbiano tolto dalle .NET 3.0 e .NET 3.0 SP1 per reintrodurlo nella .NET 3.0 SP2 per poi toglierlo di nuovo dalla .NET 3.5 e finalmente reintrodurlo nella .NET 3.5 SP1???...

[OT] Per i tanti amici milanesi: sono a Milano dall'8 di marzo e torno in Romania settimana prossima, probabilmente mercoledi' - se vi fa piacere magari si organizza un pranzo o una cena!

Quando C# e' piuttosto l'eccezione che la regola

Adrian Florea — Mon, 10 Nov 2008 21:46:00 GMT

Il comportamento del compilatore C#, presentato prima qui da Diego e poi nel mio post precedente, sembra singolare tra gli altri compilatori piu' conosciuti .NET. Il seguente snippet C# entra in stack overflow:

using System;

class Foo {
    public virtual void Write(string s) {
        Console.WriteLine("Foo virtual " + s);
    }
}

class Bar : Foo {
    public override void Write(string s) {
        Console.WriteLine("Bar override " + s);
    }

    public void Write(string s, params string[] args) {
        Write("Bar overload " + s);
    }
}

class Program {
    static void Main() {
        Bar bar = new Bar();
        bar.Write("Ciao!"); // Process is terminated due to StackOverflowException
    }
}

mentre per gli altri linguaggi, stampa Bar override Ciao! Di seguito il codice equivalente in Visual Basic .NET, C++/CLI e Visual J#

Imports System

Class Foo
    Public Overridable Sub Write(ByVal s As String)
        Console.WriteLine("Foo virtual " + s)
    End Sub
End Class

Class Bar : Inherits Foo
    Public Overrides Sub Write(ByVal s As String)
        Console.WriteLine("Bar override " + s)
    End Sub

    Public Overloads Sub Write(ByVal s As String, ParamArray args As String())
        Write("Bar overload " + s)
    End Sub
End Class

Module Program
    Sub Main
        Dim bar As Bar = New Bar
        bar.Write("Ciao") ' stampa Bar override Ciao!
    End Sub
End Module

using namespace System;

ref class Foo {
    public:
    virtual void Write(String^ s) {
        Console::WriteLine("Foo virtual " + s);
    }
};

ref class Bar : Foo {
    public:
    virtual void Write(String^ s) override {
        Console::WriteLine("Bar override " + s);
    }

    void Write(String^ s, ... array<String^>^ args) {
        Write("Bar overload " + s);
    }
};

int main() {
    Bar^ bar = gcnew Bar;
    bar->Write("Ciao!"); // stampa Bar override Ciao!
};

import System.*;

class Foo {
    public void Write(String s) {
        Console.WriteLine("Foo virtual " + s);
    }
}

class Bar extends Foo {
    public void Write(String s) {
        Console.WriteLine("Bar override " + s);
    }
    public void Write(String s, /** @attribute ParamArray() */ String[] args) {
        Write("Bar overload " + s);
    }
}

class Program {
    public static void main(String[] args) {
        Bar bar = new Bar();
        bar.Write("Ciao"); // stampa Bar override Ciao!
    }
}

Ho sempre considerato C# come linguaggio "centrale" di .NET, una chiave per capire meglio lo spirito della piattaforma - percio' mi meraviglio quando trovo comportamenti in C# che sono piuttosto l'eccezione anziche' la regola rispetto agli altri linguaggi .NET. A voi quale comportamento sembra piu' corretto/intuitivo?

Best practice Path.Combine

Adrian Florea — Sun, 04 May 2008 19:44:32 GMT

Se vogliamo che il nostro codice giri anche su Mono, dobbiamo utilizzare:

Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "aaa.bbb")

al posto di:

AppDomain.CurrentDomain.BaseDirectory + "aaa.bbb"

perche' su Mono, BaseDirectory ritorna una stringa che non finisce in Path.DirectorySeparatorChar, mentre su CLR si'. E questo va anche in generale, quando costruiamo il path da piu' pezzi, non solo nel caso della BaseDirectory. Per esempio, chi utilizza fyiReporting RDL Project su Mono, dovrebbe modificare la riga 81 nel file Runtime/RdlEngineConfig.cs nei sorgenti del progetto e ricompilare, da:

file = dir + "RdlEngineConfig.xml";

file = Path.Combine(dir, "RdlEngineConfig.xml");

perche' la stringa dir, per come e' stata costruita, su CLR finisce in Path.DirectorySeparatorChar, mentre su Mono no. In SLAR 1 alla pagina 360, Joel Marcey aggiunge questa nota sulla storia del metodo Combine:

The Combine method had an interesting ride in the standardization process. It was originally part of the Path class, then removed because it was thought to be too platform-specific, then added back because it was decided it was not any more platform-specific than any of the other methods in this class.

La risposta di Joe Duffy

Adrian Florea — Wed, 24 Jan 2007 12:15:00 GMT

Bella sorpresa trovare oggi nella casella postale una gentilissima risposta da parte di Joe Duffy, Program Manager del team del CLR, a due mail che gli avevo inviato l'agosto scorso (vedi il post "I delegate sono struct???"):

"Adrian, first I want to apologize that this mail was not responded to sooner. I found it in my “junk mail” folder for some reason.

Next, better late than never I suppose! Thank you very much for pointing both of these errors out, and also for the kind words about the book.

You are of course right in both cases. I honestly couldn’t believe I wrote those statements when I first saw your email, but sure enough I did. I have submitted them to my publisher, so they should be fixed in the next reprint.

Take care,
--joe"

Vi dico solo che il suo libro, insieme a quelli di Richter, Box, Robinson e Löwy, sono (tutti!) dei must-have per quelli che hanno la necessita' di capire a fondo .NET

L'errore CS0310 e le classi abstract

Adrian Florea — Fri, 06 Oct 2006 17:09:00 GMT

Il messaggio dell'errore CS0310 (e anche la sua descrizione) secondo me è incompleto, cioè non basta che un tipo abbia un costruttore pubblico senza parametri per poter essere utilizzato come type parameter in un tipo generico con una constructor constraint. Il messaggio dell'errore dice: "The type 'typename' must have a public parameterless constructor in order to use it as parameter 'parameter' in the generic type or method 'generic'".

Controesempio:

abstract class Foo
{
public Foo() { }
}

class Bar<T> where T : new() { }

Il tipo Foo ha un costruttore pubblico senza parametri ma l'espressione new Bar<Foo>() non compila (error CS0310).

La frase nelle specifiche C# (25.7) invece, "If the where clause for a type parameter includes a constructor constraint (which has the form new()), it is possible to use the new operator to create instances of the type" è più chiara in questo senso.

A proposito di costruttori default per classi abstract: in VB.NET è public, in C# è protected (a mio parere ha più senso che sia protected, come in C#).

System.Double.Epsilon con un pizzico di surreale

Adrian Florea — Thu, 08 Sep 2005 15:17:00 GMT

Per chi ha voglia di un pizzico di surreale, ecco uno snippet che mi ha fatto impazzire...

// foo.cs
//
// csc /d:DUMMY foo.cs # stampa False
// csc foo.cs # stampa True

using System;
using System.Diagnostics;

class Test
{
      [Conditional("DUMMY")]
      static void Dummy(double x)
      {
            x = x;
      }

      static void Main()
      {
            double x = Math.Pow(double.Epsilon, 2);
            Dummy(x);
            Console.WriteLine(0 < x && x < double.Epsilon);
      }
}

Questo codice stampa False se compilato col simbolo DUMMY e True in caso contrario, cioè l'espressione:

0 < x && x < double.Epsilon

ha valori diversi in base al fatto che Dummy (che in teoria non dovrebbe far nulla) venga chiamato prima o no...

Non ho ancora capito perché.

Obsolete assemblies

Adrian Florea — Sun, 24 Jul 2005 17:49:00 GMT

Se l'attributo System.ObsoleteAttribute avesse il target anche su AttributeTargets.Assembly, si eviterebbe di decorare tutti i tipi di un assembly interamente obsoleto come Obsolete.

Per esempio, nella Beta 2, tutti i tipi dell'assembly Microsoft.VisualC.dll sono decorati con [Obsolete(”Microsoft.VisualC.dll is an obsolete assembly and exists only for backwards compatibility.”)]. Potremmo cosi' avere, piu' semplice, una volta sola per l'intero assembly:

[assembly:Obsolete(”Microsoft.VisualC.dll is an obsolete assembly and exists only for backwards compatibility.”)]

Bug System.ComponentModel.BindableSupport.Default?

Adrian Florea — Wed, 06 Jul 2005 08:58:00 GMT

A me, il fatto che il seguente snippet stampi:

True
True
False

a console, risulta stranissimo!

using System;
using System.ComponentModel;

class Test
{
      static void Main()
      {
            BindableAttribute a = BindableAttribute.Default;
            BindableAttribute s = new BindableAttribute(BindableSupport.Default);

            Console.WriteLine(a.IsDefaultAttribute()); // True
            Console.WriteLine(s.IsDefaultAttribute()); // True

            Console.WriteLine(a.Equals(s)); // False???
      }
}

Praticamente, l'enumeration System.ComponentModel.BindableSupport, così com'è definita nel framework:

namespace System.ComponentModel
{
      public enum BindableSupport
      {
            No,
            Yes,
            Default // 2???
      }
}

vede il valore dell'elemento Default come 2 e non come 0 (che è quello di No). In effetti, nella definizione della classe System.ComponentModel.BindableAttribute, che wrappa l'enumeration di sopra, abbiamo:

namespace System.ComponentModel
{
      // ...
      public sealed class BindableAttribute : Attribute
      {
            public static readonly BindableAttribute Default = BindableAttribute.No;

            // ...
      }
}

Quindi, secondo me, il valore corretto di BindableSupport.Default sarebbe:

namespace System.ComponentModel
{
      public enum BindableSupport
      {
            No,
            Yes,
            Default = No // 0
      }
}

Cosa ne pensate?

Next version of the specification arrived, some examples still wrong

Adrian Florea — Mon, 13 Jun 2005 09:21:00 GMT

Ieri sono uscite le specifiche per la versione 8.0 (Beta 2) di Visual Basic .NET. Purtroppo, anche nella nuova versione, ho ritrovato gli stessi errori segnalati e confermati per la versione 7.1.

Devo dire che non esiste proprio paragone tra la qualità delle specifiche di C# e quelle di VB .NET e non capisco bene perché.

Launch for user

Adrian Florea — Wed, 04 May 2005 12:59:00 GMT

Non sempre quando vi appare una finestra "Just-In-Time Debugging", nel messaggio "An exception 'MyNamespace.MyException' has occurred in MyApplication.exe", l'eccezione debba essere una exception. Può capitare di incontrare al posto di 'MyNamespace.MyException', 'Launch for user' :-)

Un esempio, in questo snippet:

class Foo
{
static void Main()
{
System.Diagnostics.Debugger.Break();
}
}

Secondo me, crea un po' di confusione il messaggio.