This is amazing. I've just found you here. You are "the teacher" that everyone expects in Univerity or such. "I want to see your way of thinking", uh, yes. I work as a .NET programmer for 5 years now, but staying here for more
The answer to the C++ question is, apparently, essentially method hiding. Like C#, the compiler finds the first matching resolution in the current "scope" and according to this FAQ, "In C++, there is no overloading across scopes". One would use the "using" statement to promote the base class to the current scope.
First I should say thanks for your cool videos. My answer to the second question was => that during the runtime the class is in the heap and is called by reference, but the struct is in the stack and called by value, so it's the reason and difference between the class and struct.
If a struct is a class field, then it is on the heap. Therefore, it is possible to share a struct instance among threads by sharing the reference to its holding by-reference object. However, it is not possible to lock on the struct instance, because it has no access to the sync table entry that is required in the lock operation.
ปีที่แล้ว
Struct is FORTRANish, pass arg by value, you're right.
I have really enjoyed your videos on functional C# programming in Pluralsight, they have changed the way I code. It would be great to have you as a partner in a company, but I'm afraid I wouldn't pass your technical interviews even though I've been doing this for a few years now... 😅 Thank you very much for sharing your knowledge!
@@zoran-horvat It may, but it also may not. I've been developing/scripting call it what you will ever since I was 8 on the C64 -> Amiga -> PC. Getting my first real full-time job as a developer was not for my skill in C# but my enthusiasm and eager to learn. The Boss could see than I wasn't the most skilled but he like my enthusiasm and was willing to give me a chance. The last 6 months before that the only answer I ever got was I needed more skill and no one was willing to take a chance.
Any reference type can be used in all these scenarios because it refers the type descriptor and locking primitives. Value types don't have that in them.
Thanks for the nice video Zoran. May I offer my opinion on the subject? The first two delegates examples might be confusing to some viewers. You used the Func delegate and assigned a lambda to it. Then in the subsequent example you used lambda only. What I am trying to say is that the distinction between an explicit Func delegate declaration and the standalone lambda isn't obvious here.
It doesn't. All methods on a struct are resolved statically at compile time, from the type of the variable at hand. Type handle is procured statically and only used by the compiler. A call to GetType() on a struct variable returns a canned answer, generated by the compiler, because the variable's type is known at compile time. That is also the reason why structs cannot implement interfaces - that would allow assigning a struct to an interface variable, losing the runtime type of the object in the process. Now if you walk through these claims and compare them to a reference type, you would see that it is all opposite there - methods marked as virtual are resolved at compile time (resolving them statically is possible, but that is a compiler optimization); type handle is read from the object at run time; GetType() returns an object by traversing the type handle; when a reference type object is assigned to an interface, the information about the order of methods is effectively lost, and restored upon call by searching the method table (and caching the results to speed-up subsequent calls on the same interface variable).
@@zoran-horvat Can you clarify what you mean with "structs cannot implement interfaces"? There's nothing wrong with this example (in terms of a struct implementing an interface): IComparable aStructAsAnInterfaceVariable = new SomeStruct(); aStructAsAnInterfaceVariable.CompareTo(null); public struct SomeStruct : IComparable { public int CompareTo(object? obj) => 0; }
@@ulfakerstedt6426 I meant "cannot implement interfaces the way classes do". Type information is not stored in the steuct instance. Casting the struct instance when assigning it to an interface reference requires boxing - a slow process in which another object is created only in to hold the type information. That is the overhead we don't have with classes.
Nice video, thank you first of all. I have to tell, the Base and Derived classes example was a bit surprise for me. I though it is just a simple method overloading and I expected the "int" version will be called. It's a bit.... annoying, when things do not work on the expected way :/
As a principal developer I don't expect you to cope with details of the language, but rather with higher level designs. Anyway, which question caused you troubles?
Working working = new Working(); Animal animal1 = new Horse(); working.DoSomething(animal1); working.DoSomething((dynamic)animal1); public class Animal { } public class Horse : Animal { } public class Working { public void DoSomething(Animal animal) { Console.WriteLine("Animal"); } public void DoSomething(Horse horse) { Console.WriteLine("Horse"); } }
Become a patron and get access to source code and exclusive live streams: www.patreon.com/posts/crazy-c-with-81380655
This is amazing. I've just found you here. You are "the teacher" that everyone expects in Univerity or such. "I want to see your way of thinking", uh, yes. I work as a .NET programmer for 5 years now, but staying here for more
I've watched ~10 now. One of your best for basics!
The answer to the C++ question is, apparently, essentially method hiding. Like C#, the compiler finds the first matching resolution in the current "scope" and according to this FAQ, "In C++, there is no overloading across scopes". One would use the "using" statement to promote the base class to the current scope.
Great content - more technically orientated than a lot of other channels!
Great great teacher, keep making such videos!
Brilliant the struct and class thing was a completely new viewpoint to me kudos sir
First I should say thanks for your cool videos. My answer to the second question was => that during the runtime the class is in the heap and is called by reference, but the struct is in the stack and called by value, so it's the reason and difference between the class and struct.
If a struct is a class field, then it is on the heap. Therefore, it is possible to share a struct instance among threads by sharing the reference to its holding by-reference object. However, it is not possible to lock on the struct instance, because it has no access to the sync table entry that is required in the lock operation.
Struct is FORTRANish, pass arg by value, you're right.
I have really enjoyed your videos on functional C# programming in Pluralsight, they have changed the way I code. It would be great to have you as a partner in a company, but I'm afraid I wouldn't pass your technical interviews even though I've been doing this for a few years now... 😅 Thank you very much for sharing your knowledge!
It is easier to pass the job interview than you may think!
@@zoran-horvat It may, but it also may not. I've been developing/scripting call it what you will ever since I was 8 on the C64 -> Amiga -> PC. Getting my first real full-time job as a developer was not for my skill in C# but my enthusiasm and eager to learn. The Boss could see than I wasn't the most skilled but he like my enthusiasm and was willing to give me a chance. The last 6 months before that the only answer I ever got was I needed more skill and no one was willing to take a chance.
The third one blew my mind. Wheres the limit to that behavior? What if these were not value types but classes?
Any reference type can be used in all these scenarios because it refers the type descriptor and locking primitives. Value types don't have that in them.
Thanks for the nice video Zoran. May I offer my opinion on the subject? The first two delegates examples might be confusing to some viewers. You used the Func delegate and assigned a lambda to it. Then in the subsequent example you used lambda only. What I am trying to say is that the distinction between an explicit Func delegate declaration and the standalone lambda isn't obvious here.
Good observation.
Lamdas are only syntax sugar, according to the creator of Python.
Thanks for the video, master.
Great explenatoin. Thanks Zoran
Hi, Great as always. Could u published something like "Functional/LINQ programming with async/await" ?
I have a few topics from that area in the queue. Maybe something will come up in the near future.
Is it bad to override the equals function of a struct?
@@harisimer Not necessarily. Record structs do that.
Hi, great video! Where does a struct store it's method if it has no type handle?
It doesn't. All methods on a struct are resolved statically at compile time, from the type of the variable at hand. Type handle is procured statically and only used by the compiler. A call to GetType() on a struct variable returns a canned answer, generated by the compiler, because the variable's type is known at compile time.
That is also the reason why structs cannot implement interfaces - that would allow assigning a struct to an interface variable, losing the runtime type of the object in the process.
Now if you walk through these claims and compare them to a reference type, you would see that it is all opposite there - methods marked as virtual are resolved at compile time (resolving them statically is possible, but that is a compiler optimization); type handle is read from the object at run time; GetType() returns an object by traversing the type handle; when a reference type object is assigned to an interface, the information about the order of methods is effectively lost, and restored upon call by searching the method table (and caching the results to speed-up subsequent calls on the same interface variable).
@@zoran-horvat Can you clarify what you mean with "structs cannot implement interfaces"?
There's nothing wrong with this example (in terms of a struct implementing an interface):
IComparable aStructAsAnInterfaceVariable = new SomeStruct();
aStructAsAnInterfaceVariable.CompareTo(null);
public struct SomeStruct : IComparable
{
public int CompareTo(object? obj) => 0;
}
@@ulfakerstedt6426 I meant "cannot implement interfaces the way classes do". Type information is not stored in the steuct instance. Casting the struct instance when assigning it to an interface reference requires boxing - a slow process in which another object is created only in to hold the type information. That is the overhead we don't have with classes.
Great preview :D
Nice video, thank you first of all. I have to tell, the Base and Derived classes example was a bit surprise for me. I though it is just a simple method overloading and I expected the "int" version will be called. It's a bit.... annoying, when things do not work on the expected way :/
Yes, that is specific to C#. Morale if that story is - don't declare ambiguous methods; give them distinct names.
This is how explanation should be done.
Thanks ♥️♥️
Is the Pluralsight video's are available for free?
No, it is a paid platform which, sometimes, offers discounts on subscriptions.
I would have failed this interview. And I'm being paid over 350k by a tech giant as a principal dev.
As a principal developer I don't expect you to cope with details of the language, but rather with higher level designs.
Anyway, which question caused you troubles?
The white background made me blind
That happens, yes.
Working working = new Working();
Animal animal1 = new Horse();
working.DoSomething(animal1);
working.DoSomething((dynamic)animal1);
public class Animal { }
public class Horse : Animal { }
public class Working
{
public void DoSomething(Animal animal)
{
Console.WriteLine("Animal");
}
public void DoSomething(Horse horse)
{
Console.WriteLine("Horse");
}
}