Quick C# quiz

[Steve Naidamast]

I don't see it that way and I am a VB.NET programmer but also fluent in C#. :laugh: It is amazing how many people really view C# as some completely different type of animal than that of VB.NET... To me, the line of code was calling the method, "foo", with a string parameter...

Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com

[zezba9000]

"I know C family languages require type information to parse (which is unfortunate) but C# takes it to another level. in for a penny, in for a pound I guess." Static typing allows you to avoid runtime errors, its loads faster and much easier to find what is part of what. Sounds like you're coming from javaScript which teaches you how to think about things very wrong. A delegate in C# is a multicast-delegate in that when it invokes, its actually invoking a generated method that invokes the first function pointer, then the next and so on. It will always use virtual dispatch and can't be inlined. Don't use delegates for everything and only use them for what they're actually meant for.

[honey the codewitch]

No. I have a c++ background. I'm not talking about static versus dynamic, versus duck typing. I'm talking about parsing, an entirely different thing.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[zezba9000]

ic, sry about that

[honey the codewitch]

It might be my fault. Let's see if I can explain better: Say I'm parsing C# and I encounter the following: Console.WriteLine(Int32.MaxValue); My parser can interpret Console as a field, property, method, variable or type. Any one of them is valid here, but we can't know which it is without having type information during the parse. Similarly: Also WriteLine(Int32.MaxValue) could be a delegate invoke on a field, or property reference, or it could be a method call. You can't know during the parse without type information. That's what i mean by needing type information during the parse. It's not that strong typing is bad. It's that requiring type information during a parse dramatically complicates parsing. What I do, is I create multiple trees on a single parse, and then resolve which tree it is after i have the type information for it. Some other parsers (like microsoft's research C# GLR parser) do that too, but it's not easy. The other option is to preparse, but only up to the member definitions (ignoring method bodies and such) and then parsing again once you have all that info.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[zezba9000]

Not something I've thought about much but Is this for a lesson you can't use Roslyn for? I'm not sure how Roslyn handles using-static/type-aliases.

using static System.Console;
namespace MyNamespace
{
class Program
{
private delegate void WriteLineFunc();
private static WriteLineFunc WriteLine;

	static void Main(string\[\] args)
	{
		WriteLine();// delegate is used
	{
{

}

So if a local, field/method isn't found mark the AST node as un-resolved or add it to an un-resolved list. Then after all files are parsed go through the un-resolved nodes and try to resolve them through the aliased types. Then you don't have to parse over and over if my thinking is correct.

[honey the codewitch]

That's pretty much what I'm doing. I'm using the codedom as my ast. Every root member ref (like "foo" in foo.bar) becomes a "variable reference" with "slang:unresolved" as one of it's "user-data" keys so I can find it later. Every other member ref, like "bar" in the above is considered a field reference by default, also marked with "slang:unresolved" later on, I revisit the AST after the parse, find each of these nodes, get the scope from where I'm at and use the type information I now have to replace these "slang:unresolved" items with the appropriate references. It has served me well so far.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[User 14060113]

In C#, property, method or function names usually begin with a capital letter, whereas local variables should begin with a small letter and private member names with a prefix like "_" or "m". In C#, it is particularly important to stick to these unwritten conding rules in order to make the answer to your question more obvious:

foo

should be a local variable. But still, if you see

Foo("bar");

then Foo could be a public property name. So you can never be sure.

[honey the codewitch]

I didn't mention it, but the question was asked in context of a C# parser. How would it know what to parse without type information? :doh: It was to illustrate the complexity of the parsing of C#. The whole thing is a bit of nightmare. I recently wrote this - Slang Part 1: Parsing a C# Subset into the CodeDOM[^] to parse it, and i had to do backtracking and tree resolution with type and context info after the parse. I thought C was bad with parsing casts and pointer ops vs type*'s. Guess I didn't entirely get that point across, so my bad, but there it is.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[nullpointer 0]

He is referring to old classic VB, which of course any public function in Module can be called from anywhere.

{}*