CLS

Implementare un'interfaccia non conforme al CLS con una classe conforme al CLS

Adrian Florea — Wed, 27 Jul 2005 10:06:00 GMT

Per tantissimi sarà ovvia ma la posto brevemente, solo come osservazione: implementare un'interfaccia non conforme al CLS con una classe conforme al CLS è possibile implementando esplicitamente i membri non conformi.

Quando lo stack overflow diventa sport e C# e J# concorrenti

Adrian Florea — Tue, 12 Jul 2005 21:13:00 GMT

Questo codice, assolutamente simmetrico, l'ho scritto apposta per essere compilato sia in C# che in J#, senza modifiche:

Eseguendo il foo.exe, arriva la sorpresa: il numero di cicli che la variante J# riesce a fare (159830), supera il numero di cicli della variante C# (159781), fino al messaggio:

Process is terminated due to StackOverflowException.

Incuriosito da questa strana vittoria del J# :-) ho guardato il codice IL generato. Quando compiliamo con C#, il codice IL per i corpi dei metodi main e Main è identico. Quando compiliamo con J# invece, il corpo dell'entry point, main, è quello di Main inquadrato da:

ldtoken [vjslib]com.ms.vjsharp.lang.ObjectImpl
call void [mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::RunClassConstructor(valuetype [mscorlib]System.RuntimeTypeHandle)
// qui il corpo del Main...

all'inizio e:

// qui il corpo del Main...
call void [vjslib]com.ms.vjsharp.util.Utilities::cleanupAfterMainReturns()

alla fine.

Cos'ho provato a fare allora? Ho aggiunto nel metodo Main, cioè nell'entry point di C# seguendo il modello dell'entry point di J#, l'equivalente (C# e J#) di questi due pezzi in IL. Lo snippet è risultato così:

// foo.txt
class Test
{
      static int i = 0;

      // J# entry point
      // vjc foo.txt
      public static void main(System.String[] args)
      {
            i++;
            System.Console.WriteLine(i);
            Main(args);
      }

      // C# entry point
      // csc /r:vjslib.dll foo.txt
      public static void Main(System.String[] args)
      {
            System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(typeof(com.ms.vjsharp.lang.ObjectImpl).TypeHandle);
            i++;
            System.Console.WriteLine(i);
            main(args);
            com.ms.vjsharp.util.Utilities.cleanupAfterMainReturns();
      }
}

Ricompilando adesso in C# e in J# e rieseguendo foo, otteniamo lo stesso numero di cicli: 159830!

Si vede però come RunClassConstructor mangia un po' di stack. Se lo togliamo via lasciando solo cleanupAfterMainReturns, otteniamo addiritura un incremento del numero di cicli nella variante C#: 159914! Dal suo nome sembra che veramente faccia qualche clean up after main returns... :-) Eppure si trova dopo la chiamata di main...

toString or not ToString

Adrian Florea — Fri, 18 Mar 2005 17:27:00 GMT

Avere in un linguaggio .NET un metodo pubblico, non statico, conforme al CLS e di una classe pubblica, in un assembly, non necessariamente vuol dire che possa essere richiamato da un altro assembly!

L'esempio non è evidente: il metodo toString in questo snippet J#:

class A extends java.lang.Object
{
public String toString()
{
return "A::toString";
}
}

non può essere richiamato da C#:

class Test
{
static void Main()
{
// error CS0117: 'A' does not contain a definition for 'toString'
System.Console.WriteLine(new A().toString());
}
}

se non lo sostituiamo con ToString. Da VisualBasic .NET invece, va ("identifiers are case insensitive"):

Class Test
Shared Sub Main()
' OK
System.Console.WriteLine(New A().toString())
End Sub
End Class

E questo perché:

"In Visual J#, java.lang.Object is treated as a language-specific root of the object hierarchy. The means to access this object from languages supported by the common language runtime is through System.Object. Thus, such languages do not see Visual J# objects as special objects deriving from java.lang.Object." (Object Hierarchy Semantics)

e quindi il compilatore Visual J# "sostituisce" java.lang.Object con System.Object e toString con ToString.

Non so i compilatori .NET per gli altri linguaggi che hanno una superclasse di tutte le altre classi come la considerano - per esempio in Scala esiste una superclasse di tutte le classi, scala.Any.

CLS anche a Bucarest

Adrian Florea — Thu, 10 Mar 2005 13:47:00 GMT

Il 23 di marzo, cioè tra meno di due settimane, presenterò una sessione al workshop RONUA (ROmanian .NET User Association) a Bucarest, alla sede di Microsoft Romania (grazie a Aurelian Popa per questo invito che mi onora). L'argomento sarà sempre CLS però il contenuto e la struttura rifatti completamente rispetto alla sessione presentata a dicembre, a Milano.

RONUA, da quando ve l'ho presentato l'autunno scorso, ha fatto delle belle cose: membro INETA, 5 workshop a Bucarest (questo del 23 sarà il sesto e al quarto sono venuti Jason Zander e Brandon Bynum) e 2 a Timisoara, 122 membri e ultimamente degli ottimi post sul forum. Per il suo primo mezzo anno di vita mi sembra tanto! Se avete qualche idea di collaborazione UGIdotNET-RONUA (cene comprese) vi prego di contattarmi appena vi vengono :-)

I versi del giorno:

Tutte le città del mondo
oasi delle nostre noie affamate
offrono bevande fresche

Philippe Soupault - Westwego (1917-1922)

Quiz Sharp #41

Adrian Florea — Wed, 08 Dec 2004 20:00:00 GMT

Chi ha seguito la mia sessione al workshop del 2 dicembre già lo conosce. Per gli altri, qui sotto, una domandina:

Cosa producono i seguenti due pezzi di codice?

C#	Visual Basic .NET
[IndexerName("P")] public string this[int i] { get { return _p[i]; } set { _p[i] = value; } }	<IndexerName("P")> _ Public Property Item(ByVal i As Integer) As String Get Return _p(i) End Get Set(ByVal Value As Integer) _p(i) = Value End Set End Property

Consumare da C# codice Delphi non-CLS

Adrian Florea — Tue, 30 Nov 2004 01:27:00 GMT

Abbiamo visto nel post precedente come il compilatore Delphi crea una classe finta per ogni unit così che anche il codice procedurale soddisfi la regola CLS 36. Cosa succede invece quando non gli lasciamo più spazio agli trucchi e trasgrediamo in modo esplicito una regola CLS, per esempio la CLS Rule 11 (quella sulla signature)? Potremmo da C# "consumare" un codice come quello di seguito? (al tipo Word di Delphi corrisponde in C# il tipo ushort, non CLS)

// DelphiCls.pas
library DelphiCls;

uses
Foo in 'Foo.pas';

// inutile: Delphi non è CLS-compliant
[assembly: CLSCompliant(True)]

begin
end.

// Foo.pas
unit Foo;

interface

// non ha una signature conforme al CLS
function BadArgType(i: Word): Word;

implementation

function BadArgType(i: Word): Word;
begin
Result := i + 1;
end;

end.

La risposta è sì:

// C#
using System;
class Test
{
static void Main()
{
    ushort i = 2;
    Console.WriteLine(Foo.Units.Foo.BadArgType(i)); // scrive 3
    Console.Read();
}
}

Qualcuno sa perché, prima che arrivi il giovedì?

Gli errori C# relativi esplicitamente al CLS

Adrian Florea — Mon, 29 Nov 2004 01:19:00 GMT

Nel file "errors.h" che contiene la lista di tutti gli errori e warning del compilatore C# del Rotor c'è scritto che "Range 3000-3999 is reserved for CLS errors". Qui sotto nella tabella, ho mappato gli errori C# riguardanti esplicitamente il CLS alle regole del CLS trasgredite:

Visual C# Compiler Error / Warning Number	Rotor Error Name	Summary	Description	CLS Rule Number	CLS Rule
?	ERR_CLS_NoVarArgs	?	?	?	?
CS3001	ERR_CLS_BadArgType	Argument type 'type' is not CLS-compliant	A public, protected, or protected internal method must accept a parameter whose type is compliant with the CLS.	11	All types appearing in a signature shall be CLS-compliant. (p. 49 del PDF)
CS3002	ERR_CLS_BadReturnType	Return type of 'method' is not CLS-compliant	A public, protected, or protected internal method must return a value whose type is compliant with the CLS.	11	(vedi sopra)
CS3003	ERR_CLS_BadFieldPropType	Type of 'variable' is not CLS-compliant	A public, protected, or protected internal variable must be of a type that is compliant with the CLS.	11, 27	(vedi sopra per 11) [The type of a property] shall be CLS-compliant, and shall not be managed pointers (i.e. shall not be passed by reference). (p. 64 del PDF)
CS3004	ERR_CLS_BadUnicode	Mixed and decomposed Unicode characters are not CLS-compliant	Only composed Unicode characters are allowed in public, protected, or protected internal identifiers in order to be compliant with the CLS.	4	Assemblies shall follow Annex 7 of Technical Report 15 of the Unicode Standard 3.0 (ISBN 0-201-61633-5) governing the set of characters permitted to start and be included in identifiers. Identifiers shall be in the canonical format defined by Unicode Normalization Form C. For CLS purposes, two identifiers are the same if their lowercase mappings (as specified by the Unicode locale-insensitive, 1-1 lowercase mappings) are the same. That is, for two identifiers to be considered different under the CLS they shall differ in more than simply their case. However, in order to override an inherited definition the CLI requires the precise encoding of the original declaration be used. (p. 44 del PDF)
CS3005	ERR_CLS_BadIdentifierCase	Identifier 'identifier' differing only in case is not CLS-compliant	A public, protected, or protected internal identifier, which differs from another public, protected, or protected internal identifier only in the case of one or more letters, is not compliant with the CLS.	4	(vedi sopra)
CS3006	ERR_CLS_OverloadRefOut	Overloaded method 'method' differing only in ref or out is not CLS-compliant	A method does not cannot be overloaded based on the ref or out parameter and still comply with the CLS.	38	Properties, instance methods, and virtual methods may be overloaded based only on the number and types of their parameters, except the conversion operators named op_Implicit and op_Explicit which may also be overloaded based on their return type. (p. 72 del PDF)
CS3008	ERR_CLS_BadIdentifier	Identifier 'identifier' is not CLS-compliant.	A public, protected, or protected internal identifier breaks compliance with the CLS if it begins with an underscore character "_".	4	(vedi sopra) da vedere anche il mio post precedente
CS3009	ERR_CLS_BadBase	'type': base type 'type' is not CLS-compliant.	A base type was marked as not having to be compliant with the CLS in a module that was marked as being CLS compliant. Either remove the attribute that specifies the module is CLS compliant or remove the attribute that indicates the type is not CLS compliant.	?	?
CS3010	ERR_CLS_BadInterfaceMember	'member': CLS-compliant interfaces must have CLS-compliant members	In a module marked with [assembly:CLCSompliant(true)], an interface contains a member marked with [CLCSompliant(false)]. Remove one of the CLS compliance attributes.	18	CLS-compliant interfaces shall not require the definition of non-CLS compliant methods in order to implement them. (p. 55 del PDF)
CS3011	ERR_CLS_NoAbstractMembers	'member': only CLS-compliant members can be abstract	A class member cannot be both abstract and non-compliant with the CLS. The CLS specifies that all class members shall be implemented.	?	?
CS3012	ERR_WRN_NotOnModules Compiler Warning (level 1)	You must specify the CLSCompliant attribute on the assembly.	In order for a module to be compliant with the CLS through [module:System.CLCSompliant(true)], it must be built with the /target:module compiler option.	-	-
CS3013	ERR_CLS_ModuleMissingCLS	Added module is not CLS-compliant, or is missing CLSCompliant attribute.	A module that was compiled with the /target:module compiler option was added to a compilation with /addmodule. However, the module's compliance with the CLS does not agree with the CLS state of the current compilation. CLS compliance is indicated with the module attribute. For example, [module:CLSCompliant(true)] indicates that the module is CLS compliant, and [module:CLSCompliant(false)] indicates that the module is not CLS compliant. The default is [module:CLSCompliant(false)].	-	-
CS3014	ERR_CLS_AssemblyNotCLS	'member' cannot be marked as CLS compliant because the assembly is not marked as compliant	In a source code file where compliance with the CLS was declined, a construct in the file was marked as being CLS compliant. This is not allowed. Remove one of the CLSCompliant specifications.	2	Members of non-CLS compliant types shall not be marked CLS-compliant. (p. 36 del PDF)
CS3015	ERR_CLS_BadAttributeType	'method signature' has no accessible constructors which use only CLS compliant types.	To be compliant with the CLS, the argument list of an attribute class cannot contain an array.	34	The CLS only allows a subset of the encodings of custom attributes. The only types that shall appear in these encodings are: System.Type, System.String, System.Char, System.Boolean, System.Byte, System.Int16, System.Int32, System.Int64, System.Single, System.Double, and any enumeration type based on a CLS-compliant base integer type. (p. 69 del PDF)
CS3016	ERR_CLS_ArrayArgumentToAttribute	Arrays as attribute arguments is not CLS-compliant.	It is not compliant with the CLS to pass an array to an attribute.	34	(vedi sopra)

E' interessante notare che il warning CS3012, l'unico warning in questa serie composta solo da errori di non conformità al CLS, riguarda non il linguaggio ma le opzioni di compilazione che devono essere coerenti con il codice. All'inizio mi sono chiesto: ma sarà per questo che i tizi del Visual C# Team l'hanno scelto come warning e non come errore? Poi, ho visto anche la situazione simile dell'errore CS3013, che non è warning ma errore e quindi il ragionamento forse non vale. Sono stato un po' indeciso tra mettere un punto di domanda e mettere un trattino per questi due, ma alla fine ho scelto il trattino.

Un'altra osservazione è che il compilatore C# del Rotor sembra avere un errore in più per il CLS, ERR_CLS_NoVarArgs, molto probabilmente riguardante la CLS Rule 15: "The varargs constraint is not part of the CLS, and the only calling convention supported by the CLS is the standard managed calling convention." (p. 51 del PDF). Ho lasciato però un punto di domanda.

Non ho trovato una regola CLS corrispondente all'errore CS3009, anche se sarei tentato al limite di associargli la CLS Rule 20: "CLS-compliant classes, value types, and interfaces shall not require the implementation of non-CLS-compliant interfaces." (p. 58 del PDF). La regola però si riferisce chiaramente a interface non conforme al CLS.

La stessa CLS Rule 20 l'associerei all'errore CS3011 con la stessa osservazione.

Qualche commento?

L'underscore e la CLS Rule 4

Adrian Florea — Sun, 28 Nov 2004 17:23:00 GMT

Mi ha attirato l'attenzione un commento di Massimo Prota a questo post di Pierre. Beh, riguarda CLS, di cui vi parlerò giovedì - a sala vuota mi sa... :-)

Massimo segnalava in sostanza il fatto che in un assembly conforme al CLS non possiamo nominare gli identificatori dei campi protected con il prefisso "_" in una classe public.

Ne approfitto per aggiungere delle cose magari meno conosciute:

Beccare tra le 41 regole del CLS quella responsabile di questo vincolo non è immediato. Dovreste leggervi l'appendice 7 "Programming Language Identifiers" dell'"Unicode Technical Report #15" (come specificato dalla CLS Rule 4 - p. 44 del PDF del testo dello standard ECMA-335). Però lì non incontrerete alcun riferimento all'underscore. Semplicemente, l'underscore non si trova nell'elenco:

"the first character of an identifier can be an uppercase letter, lowercase letter, titlecase letter, modifier letter, other letter, or letter number"
che definisce l'elemento . E se "_" non si trova, non è soddisfatta la regola 4 del CLS.
Questo è un errore che dà il compilatore C# (l'errore CS3008). Visual Basic non lo segnala come errore e possiamo tranquillamente avere:

' Visual Basic .NET
Imports System
<Assembly: CLSCompliant(True)>
Namespace VisualBasic
Public Class ClsRule4
    ' OK
    Protected _underscorePrefixed As String
End Class
End Namespace

// Visual C# .NET
using System;
[assembly:CLSCompliant(true)]
namespace CSharp
{
public class ClsRule4: VisualBasic.ClsRule4
{
    public void Foo()
    {
      Console.WriteLine(_underscorePrefixed);
    }
}
}

ma non il caso simmetrico:

// Visual C# .NET
using System;
[assembly:CLSCompliant(true)]
namespace CSharp
{
public class ClsRule4
{
    // error CS3008: Identifier 'CSharp.ClsRule4._underscorePrefixed' is not CLS-compliant
    protected string _underscorePrefixed;
}
}

' Visual Basic .NET
Imports System
<Assembly: CLSCompliant(True)>
Namespace VisualBasic
Public Class ClsRule4 : Inherits CSharp.ClsRule4
    Public Sub Foo()
      Console.WriteLine(_underscorePrefixed)
    End Sub
End Class
End Namespace
Guardando nei sorgenti del Rotor sono arrivato al file "clsdrec.cpp" dove, all'interno della CLSDREC::checkCLSnaming si nota la verifica non solo in base all'underscore (0x005F) ma anche al carattere (0xFF3F) che significa in Unicode "FULLWIDTH LOW LINE". Se provate invece in Visual C# .NET a dichiarare un membro che inizi con \uff3f non vi dà errore di non conformità al CLS ma:

Invalid token '' in class, struct, or interface member declaration
Invalid token ';' in class, struct, or interface member declaration

~~Massimo ha fatto anche un piccolo errore, sicuramente per la fretta del commento: ha incluso anche il camelCase nelle nomenclature non conformi al CLS.~~

E nell'altra sala ci sarà Andrea :-)

Adrian Florea — Sun, 10 Oct 2004 22:34:00 GMT

Il 2 di dicembre presenterò al workshop "Architecture & Management" una sessione su "CLS: regole per compilatori e per sviluppatori".

Inizio proprio in modo "potente" :-) visto che nell'altra sala ci sarà proprio Andrea... L'argomento che presento però mi piace da morire: è veramente poco conosciuto (ho guardato il webcast di Marco Russo "Ambiente object-oriented, CTS, CLS, FxCop" e la farò ben diversa) e in più è un argomento pieno-pieno di sorprese.

Ah, un'altra cosa: visto il mio accento straniero, cercherò di parlare in IL, così mi capirete tutti :-)