C# Questions
-
- Because if it didn't it wouldn't know when you wanted to create a new instance:
MyClass[] data = new MyClass[10];
MyClass instance;
for (int i = 0; i < 10; i++)
{
data = instance;
}How many different instances of MyClass should that produce? Zero? One? Ten? Or Eleven?
MyClass[] data = new MyClass[10];
MyClass instance;
for (int i = 0; i < 10; i++)
{
instance = new MyClass();
data = instance;
}Makes that abundantly clear. 2) See previous answers, particularly Pete's 3) Yes. Again, see Pete's answer. 4) No, thank goodness. D/V was good in it's time, but thankfully things have moved on a lot since those primitive days.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
1. Because the new keyword tells the application to instantiate an object at that point. If we have several different constructors on an object, new is a great way to tell the application that you expect a certain constructor to be invoked at that point. Merely referencing the object wouldn't be a great place to instantiate it because you could instantiate it long before you need it - and this would play hell doing things like building class factories. 2. Get is synctatic sugar that hides the fact that you are actually calling a special method with the prefix get_, so your code has to follow the standards of other methods. Another point to consider is, how would you indicate what you are returning? It's quite common to have some form of lazy initialisation or return choice in the getter, so you have to have some functionality in there to indicate what's going to be returned. Of course, if you don't actually need to do anything, just create an automatic property and you don't have to write a return statement (although one is implicitly created behind the scenes). 3. Yes. The .NET runtime and .NET applications are still PE Format applications. 4. That's just a pattern. While there's no default implementation of it in the framework, it's incredibly trivial to create although, as anyone who's worked with DocView will attest, the DocView pattern is severely limited in what it can do. There are a number of superior patterns available to use, such as MVC.
-
thanks ... I guess my question on "new" is why isn't it just automatic? with C# it call delete for you. So why not new also? would you ever not use it?
Simply because C# doesn't try to "guess" what you wanted. Think about it: I don't want the system creating a new instance every time I try to use an existing one, because it means a trip to the DB and back to create an item that I may not use again - and the "real" DB item then doesn't get updated. I want the system to create an instance only when I specifically tell it to. If the system created them for me, then
MyClass[] data = MyClass[10];
Would create an array of references to MyClass instances and the instances to fill it with. I may not want that: if MyClass always contains an enormous Bitmap (for example) that is a huge amount of time and memory being wasted, because I'm about to fill the array with the top ten instances from the DB when I call the method below it:
MyClass[] data = MyClass[10];
DAL.GetImageData(data, 10, "SEARCH CONDITION");But the system can't know that because it doesn't have any idea what the method does - it's in a separate DLL! The
newkeyword allow you to specify exactly when you want an instance created (and reminds you that this could take some time and / or resources when it does it)Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
thanks ... I guess my question on "new" is why isn't it just automatic? with C# it call delete for you. So why not new also? would you ever not use it?
BTW:
shiftwik wrote:
with C# it call delete for you
No, it doesn't - it calls Dispose for you, but not at a time of your chosing, unless you specifically add a
usingblock: objects are only ever deleted when the Garbage Collector gets around to it, which may never happen! :laugh:Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
1. Why does C# require the "new" keyword? why bother?? it's not like C++ where you need the functionality of memory allocation and calling the constructor 2. why does C# require the "return" keyword with a "get" function. What else would you use a get function for? besides returning data?? seems like an extra step where "get" is built in to the language 3. When CLR executes your code is the .net "engine" accessing kernel, user and or gdi.dll ? or does it have some other method of communicating with windows os kernel functions? 4. Does C# have an equivalent to the Doc/View architecture for windows apps? thanks
2. You could do something like this:
public int LimitedInt{
get{
if(mylimitedint < 0){
limitedint = 0;
}
if(limitedint > 42){
limitedint = 42;
}
return limitedint;
}
}3. Yes everything that has something to do with the OS will pass through the kernel, but it passes through the .NET framework first. IOW the framework adds functionality to your code. Among many things Garbage Collection, Exception handling etc ...
V.
(MQOTD rules and previous solutions) -
BTW:
shiftwik wrote:
with C# it call delete for you
No, it doesn't - it calls Dispose for you, but not at a time of your chosing, unless you specifically add a
usingblock: objects are only ever deleted when the Garbage Collector gets around to it, which may never happen! :laugh:Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Disposewill only ever be called at a time of your choosing - either from the end of ausingblock, or when you explicitly call it. It's the finalizer -~ClassName(){ ... }- that gets called by the GC at some random time in the future.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
"These people looked deep within my soul and assigned me a number based on the order in which I joined" - Homer
-
Disposewill only ever be called at a time of your choosing - either from the end of ausingblock, or when you explicitly call it. It's the finalizer -~ClassName(){ ... }- that gets called by the GC at some random time in the future.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
:doh: Yes, you are right - and the finalizer should call Dispose(false)... I plead stupidity...and a lack of caffeine.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
:doh: Yes, you are right - and the finalizer should call Dispose(false)... I plead stupidity...and a lack of caffeine.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Should call Dispose if you are implementing the IDisposable Interface :-\ You usually only use it to ensure that unmanaged resources are released, to prevent memory leaks. Either immediatly when
Disposegets called or when the GC calls theFinalizeMethod (which you have to override in that case), in case it didn't get called by the code which held the reference to it. You might also use it to free resources before the GC kicks in (by setting large fields like lists etc. to null and thus making it easier for the GC to collect those resources). ;P -
Should call Dispose if you are implementing the IDisposable Interface :-\ You usually only use it to ensure that unmanaged resources are released, to prevent memory leaks. Either immediatly when
Disposegets called or when the GC calls theFinalizeMethod (which you have to override in that case), in case it didn't get called by the code which held the reference to it. You might also use it to free resources before the GC kicks in (by setting large fields like lists etc. to null and thus making it easier for the GC to collect those resources). ;PNicholas Marty wrote:
Should call Dispose if you are implementing the IDisposable Interface :-\
If your class has a finalizer and doesn't implement
IDisposable, that's almost certainly a bug. I can't think of any reason why your class would say, "I want this resource to possibly be cleaned up at some unknown point in the future, but I don't want the calling code to be able to clean it up immediately".
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Nicholas Marty wrote:
Should call Dispose if you are implementing the IDisposable Interface :-\
If your class has a finalizer and doesn't implement
IDisposable, that's almost certainly a bug. I can't think of any reason why your class would say, "I want this resource to possibly be cleaned up at some unknown point in the future, but I don't want the calling code to be able to clean it up immediately".
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Every Type has a finalizer as every object inherits from
System.Objectat some point. You may or may not override it. But it still has a finalizer ;) -
Every Type has a finalizer as every object inherits from
System.Objectat some point. You may or may not override it. But it still has a finalizer ;)The Object class provides no implementation for the Finalize method, and the garbage collector does not mark types derived from Object for finalization unless they override the Finalize method.
So whilst it's technically true that every object has a finalizer, only objects which override the finalizer will be marked for finalization. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
The Object class provides no implementation for the Finalize method, and the garbage collector does not mark types derived from Object for finalization unless they override the Finalize method.
So whilst it's technically true that every object has a finalizer, only objects which override the finalizer will be marked for finalization. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Yeah. And you should suppress the finalization of the object if you disposed the object already :) And yeah, if you override the finalizer you should probably also use the IDisposable pattern.
-
Simply because C# doesn't try to "guess" what you wanted. Think about it: I don't want the system creating a new instance every time I try to use an existing one, because it means a trip to the DB and back to create an item that I may not use again - and the "real" DB item then doesn't get updated. I want the system to create an instance only when I specifically tell it to. If the system created them for me, then
MyClass[] data = MyClass[10];
Would create an array of references to MyClass instances and the instances to fill it with. I may not want that: if MyClass always contains an enormous Bitmap (for example) that is a huge amount of time and memory being wasted, because I'm about to fill the array with the top ten instances from the DB when I call the method below it:
MyClass[] data = MyClass[10];
DAL.GetImageData(data, 10, "SEARCH CONDITION");But the system can't know that because it doesn't have any idea what the method does - it's in a separate DLL! The
newkeyword allow you to specify exactly when you want an instance created (and reminds you that this could take some time and / or resources when it does it)Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
To add to your excellent reply: related is lazy initialization lazy initialization[^] The .net framework convenieitly offers direct support: the Lazy Class[^]
Erik Westermann
