Bugs?

Best practice Path.Combine

Adrian Florea — Mon, 05 May 2008 09: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 — Thu, 25 Jan 2007 01: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 — Sat, 07 Oct 2006 07: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 — Fri, 09 Sep 2005 05: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 — Mon, 25 Jul 2005 07: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 22: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 23: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 — Thu, 05 May 2005 02: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.

Errore in SLAR sul parser SecurityElement

Adrian Florea — Mon, 11 Apr 2005 20:26:00 GMT

In SLAR alla pagina 389 c'è scritto che:

"This class is used only by the system; applications cannot create instances of the System.Security.SecurityElement type"

Questa affermazione non è vera: la classe SecurityElement è in sostanza un parser XML leggero (sa parsare solo elementi, attributi e testo) e può essere utilizzata come qualunque altra classe. Un bellissimo esempio è mostrato in questo post di Shawn Farkas sulla trasformazione SecurityElement <-> XmlElement. Lo dimostra anche l'esempio che si trova in SLAR nella stessa pagina (la classe Samples.SecurityElementSample).

I bug degli esempi su RaiseEvent, confermati da Paul Vick

Adrian Florea — Mon, 04 Apr 2005 23:12:00 GMT

Visto che non ricevo tutti i giorni una mail da Paul Vick, la posto :-)

Adrian,

Thank you so much for your email! You are correct that the examples are wrong... it looks like they somehow slipped through our editing process!
I'll make sure that they are corrected in the next version of the specification, which should be coming out with Beta2 of VB 2005.

Thanks so much for the bug reports!

Paul

La mail conferma i bug segnalati in un post precedente. Gli indirizzi MSDN degli esempi errati sono: