Hi,
last week a few new topics have been added. As usual, comments and corrections are welcome!
The Preprocessor
Literals
Delegates
Naming conflicts
CreateInstance() and Libraries
Wolfgang
The X# Documentation Project
The X# Documentation Project - new topics last week
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
The X# Documentation Project - new topics last week
Hi Wolfgang,
great, to see the progress!
One thing i just saw in Delegates:
"...a signature is the number and types of parameters and the type of return value)."
AFAIK, the return type is NOT part of the signature, e.g., the compiler will not accept:
HTH
Karl
great, to see the progress!
One thing i just saw in Delegates:
"...a signature is the number and types of parameters and the type of return value)."
AFAIK, the return type is NOT part of the signature, e.g., the compiler will not accept:
Code: Select all
CLASS z
METHOD x(a AS STRING) AS INT32
RETURN 1
METHOD x(a AS STRING) AS STRING
RETURN "1"
END CLASS
Karl
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
The X# Documentation Project - new topics last week
Hi Karl,
of course you are right. I will correct that today.
Thank you very much!
Wolfgang
of course you are right. I will correct that today.
Thank you very much!
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
The X# Documentation Project - new topics last week
Guys,
Looks like there are conflicting views on what is a signature, depending on the context the return type is part of it or it isn't. For example, from https://stackoverflow.com/questions/880 ... in-c-sharp :
There are two definitions of method signature. The C# language definition does not include the return type, and uses the signature of the method to determine whether two overloads are allowed. Two methods with the same signature are not allowed in a type. Since C# does not consider the return type to be a part of the signature, C# does not allow two methods that differ only in return type to be declared in the same type.
The CLR, however, does include the return type in the signature. The CLR allows for two methods to be in the same type that differ only in return type.
I think I also like this definition form https://docs.microsoft.com/en-us/dotnet ... ts/methods :
A return type of a method is not part of the signature of the method for the purposes of method overloading. However, it is part of the signature of the method when determining the compatibility between a delegate and the method that it points to.
So, in short, maybe we shouldn't say that a delegate much have the same signature with the method, but in order to avoid ambiguity, let's say that the delegate must have the same parameters and return type as the method, which is more clear. A shame, since "same signature" is much easier to say
Chris
Looks like there are conflicting views on what is a signature, depending on the context the return type is part of it or it isn't. For example, from https://stackoverflow.com/questions/880 ... in-c-sharp :
There are two definitions of method signature. The C# language definition does not include the return type, and uses the signature of the method to determine whether two overloads are allowed. Two methods with the same signature are not allowed in a type. Since C# does not consider the return type to be a part of the signature, C# does not allow two methods that differ only in return type to be declared in the same type.
The CLR, however, does include the return type in the signature. The CLR allows for two methods to be in the same type that differ only in return type.
I think I also like this definition form https://docs.microsoft.com/en-us/dotnet ... ts/methods :
A return type of a method is not part of the signature of the method for the purposes of method overloading. However, it is part of the signature of the method when determining the compatibility between a delegate and the method that it points to.
So, in short, maybe we shouldn't say that a delegate much have the same signature with the method, but in order to avoid ambiguity, let's say that the delegate must have the same parameters and return type as the method, which is more clear. A shame, since "same signature" is much easier to say
Chris
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
The X# Documentation Project - new topics last week
Hi Chris,
thank you very much for your clarification! I will change the documentation topic as suggested.
Wolfgang
thank you very much for your clarification! I will change the documentation topic as suggested.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
The X# Documentation Project - new topics last week
Hi Chris, hi Karl,
I have now updated the topic:
https://docs.xsharp.it/doku.php?id=delegates
I hope this is now ok.
IMHO contributions like yours are very precious because they make the content of the wiki better.
Wolfgang
I have now updated the topic:
https://docs.xsharp.it/doku.php?id=delegates
I hope this is now ok.
IMHO contributions like yours are very precious because they make the content of the wiki better.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
The X# Documentation Project - new topics last week
Wolfgang,
yes, probably better. Although: following your net-information link one finds:
Sloppy use of language causes much unnecessary pain
And, we should try to produce "striking" samples for coding concepts.
See the sample, also from above link:
doesn't help me much to understand, why i should use the concept at all..:dry:
Karl
yes, probably better. Although: following your net-information link one finds:
Notice the "should"...A delegate is independent of the type of method that it references. The signature of the method and the delegate should match.
Sloppy use of language causes much unnecessary pain
And, we should try to produce "striking" samples for coding concepts.
See the sample, also from above link:
Code: Select all
//A class method
public void add(int n1, int n2)
{ MessageBox.Show("Adding numbers : " + (n1 + n2).ToString()); }
//invocaton
Form1 form1 = new Form1();
delegateMethod addNumbers = new delegateMethod(form1.add);
addNumbers(50, 10);
Karl
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
The X# Documentation Project - new topics last week
Hi Karl,
About better samples: I will try to add a sample.
But like in VO we don't used function pointers when not needed by an external API (we had codeblocks - much better), the .NET languages don't need delegates when not required by an external API (in .NET we have lambdas and commands - much better than a delegate).
Therefore I will add a delegate sample from one of my migrated VO libraries - where a Windows API function requires a callback function and in X# a delegate is needed (the Xporter replaces callbacks by delegates).
Wolfgang
I have no problem to say: must. If you try to set the delegate variable to a method that does not match, the compiler states clearly:A delegate is independent of the type of method that it references. The signature of the method and the delegate should match.
Notice the "should"...
Code: Select all
error XS0123: No overload for 'Execute3' matches delegate 'IntDelegate'
But like in VO we don't used function pointers when not needed by an external API (we had codeblocks - much better), the .NET languages don't need delegates when not required by an external API (in .NET we have lambdas and commands - much better than a delegate).
Therefore I will add a delegate sample from one of my migrated VO libraries - where a Windows API function requires a callback function and in X# a delegate is needed (the Xporter replaces callbacks by delegates).
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
The X# Documentation Project - new topics last week
Good morning Wolfgang!
Fine, thx.
FTR, i didn't want to question "you" or your samples, i admire very much your commitment to promote this project!
My critique points at all the self-called "experts" which post sloppy lectured content...
HAND
Karl
Fine, thx.
FTR, i didn't want to question "you" or your samples, i admire very much your commitment to promote this project!
My critique points at all the self-called "experts" which post sloppy lectured content...
HAND
Karl
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
The X# Documentation Project - new topics last week
Hi Karl,
no problem at all! I'm very, very far from being perfect, or even from knowing the X# language or the .NET framework very well, so every correction of my text or my samples is welcome.
I had some errors, and Chris gave me several corrections or enhancements, so many of my topics contain informations from Chris or other people.
Only joined forces can help to make and keep the wiki a useful information source (where the "keep" may be much harder than "make").
Wolfgang
no problem at all! I'm very, very far from being perfect, or even from knowing the X# language or the .NET framework very well, so every correction of my text or my samples is welcome.
I had some errors, and Chris gave me several corrections or enhancements, so many of my topics contain informations from Chris or other people.
Only joined forces can help to make and keep the wiki a useful information source (where the "keep" may be much harder than "make").
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it