I was studying for my test today and I came accross the sentence
System.Console.WriteLine();
Could some one tell me what the System stands for cause when I remove it i dont see any diffrence.
System is just the namespace which contains the Console type.
You almost certainly have a using directive like this in your code:
using System;
That imports every type within the namespace, so you can refer to it by its simple name. Without that directive, you would see a difference - System.Console would still work, but just Console wouldn't, because the compiler wouldn't know which type you meant.
The System is the name of the namespace the class Console resides in. You need to give the full name or it won't compile. With one exception: if you have a line using System; on top of your file, whenever something cannot be found, a namespace of System will be assumed for lookup.
System is a Namespace. You will find it in the head of your code.
using System;
If you remove using System;, you will find Console.WriteLine(); can't be complied.
System refers to the main library that contains the fundamental classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions. And Console type is one of them.
the reason why you are not getting a difference is that it's referenced by default in the top of your class page
The System in System.Console.WriteLine() refers to the System namespace. Therefore, if you're importing System in your code, it's redundant to call the WriteLine method using that namespace.
http://msdn.microsoft.com/en-us/library/System(v=vs.110).aspx
Just the namespace where Console.WriteLine() resides
which is a default import (using system)
Related
McCarson.LearningToCode.Week(3);
Adding to give context to set experience expectations
I have seen developers import references on the code behind for very specific elements within a library as well as import references for the entire library itself irrelevant of whatever the needed element is. How much memory is conserved (if any) with the specific element needed being referenced for the page, to the point that, is it considered best practice to only import the needed element or is it a trivial concern? (I did see that it marginalizes room for error)
I researched MSDN, did not find the answer so asking here seems like a logical choice
Using/Importing is first a shorthand to avoid having to use fully qualified type names (Namespace + Classname).
There might be performance considerations too, but only while writing the code - not at runtime. Regardless how you write your code, the IL will still use a fully qualified typename. If you do not give a fully qualified name, Compiler and Intellisense kind of have to "guess" in wich used namespace the class you reference resides. Wich 95% of the cases works without any issues.
Using/Importing whole namespaces can have issues from a Ambiguity point of view. For example, there are at least 3 Namespaces with a "Timer" class. Each of them is a different type, with different bebavior and different Proeprties/Events.
If you using/import any two of those Namesapces, the classname "Timer" is no longer ambigious like "string" or "object" is. So all of a sudden, you have to use the fully qualified name for all Timer instances once again.
So in very rare circumstances, using/importing the whole namespace on a global level will cause you no end of issues. Hence it can be preferable to limit both the scope and the depth of a use/include directive.
It can be negligible to make using / importswhen there is no need but it can also harm performance (depends on your program and the referenced assembly size and hypersensitivity to performance) and its a bad programming habit.
the meaning of every using / imports statement is that the compiler will search properties / methods / classes etc within that assembly. also you must take into account the order of the using statements - the compiler will search according to the order of the using statements.
BTW - there is a small difference between VB.NET and C# - VB imports the major namespaces by default opposed to C#.
by saying major namespaces (.net framework 4.6):
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
and as #Chillzy wrote in his comment VS will color
unnecessary imports in dark gray.
I was under review of team code. I observe they had used class ClassAby writing using AAA.BBB; at the upper portion of the class; also they have sometime used class ClassB by AAA.BBB.ClassB. There are two basic questions.
Is there any performance issue while using above scenario. What is recommended
When I declare namespace; are all classes get loaded of that namespace or not.
Please assist here. Thanks.
I'll answer these as best as I can, I don't have any sources on hand, just experience (maybe someone can help with that).
There is no performance issue with importing a namespace versus calling it directly. When the compiler runs through it, you can think of it as always being fully qualified in the end. The using statement for namespaces is more to assist the developer so they don't have to fully qualify it each time. In fact, for your ClassB example, it could be that there is a collision with multiple namespaces defining the same class name. For example, the Calendar class is both in System.Globalization and System.Web.UI, so you have to fully qualify one or the other when using them.
Generally, all code is compiled into an assembly by the project it's under. Referencing any code inside of the assembly will load all of the associated code. Note, however that the code isn't necessarily compiled for use by the JIT until it's actually called.
Namespaces are for organizing your code (while preventing name collisions). They have no bearing on performance at all.
Fully qualified names in code are distracting and noisy. I prefer to never have them. If there is a namespace conflict, a using alias can resolve that.
only for places where there is a conflict with there being two Class defined in different namespaces, and, even then, I'll still rather use a using to differentiate them:
using MyClassB=AAA.BBB.ClassB;
// :
var myClassB= new MyNS();
in terms of performance, you can see the answer here:
The using directive is only syntactic sugar that disappears during
compilation. Whether or not the namespace was included via using or
mentioned in a fully-qualified type name is totally irrelevant in the
resulting bytecode. Hence, there is no performance benefit at runtime
by using one or the other.
This is such a dumb question, but I can't figure out the lingo to ask Google.
In Java if I wanted to import all subclasses I would use something like
java.util.*
And all of util would be imported.
Firstly, what is the proper lingo for what I'm doing in C# so I can start using Google more effectively. Am I importing namespaces? Libraries? Subclasses? (Can you tell I'm new at this?)
Secondly, since I'm here, how is this accomplished in C#?
PS- I did click on every related question stackOverflow threw at me to see if the answer would pop up. No luck. I'm simply without words to describe what I'm looking for. The example should do just fine but... Anyone who can take a moment to either explain the lingo to me or perhaps simply point me at something that can (in a nutshell, I have a couple books for the long haul) that would be great.
Firstly, let's differentiate between assembly references and namespaces.
Assemblies are what you add references to in your c# project, they are the libraries that contain the actual classes you need, usually found as DLL files. The .net framework contains many such assemblies, and Visual Studio will try to reference the most commonly used ones in your project (e.g. for a WinForms project it will automatically add a reference to System.Drawing.dll).
Namespaces are logical partitions of the classes in an assembly.
Once you reference an assembly in the project, all classes in all namespaces are available for use, if you provide their full name.
This is where the using directive comes in.
It is simply syntactic sugar for not having to write very long names all the time.
For example, assuming your project references the System.Drawing.dll assembly, you would have to qualify a class from this assembly using it's full name, for example
System.Drawing.Imaging.BitmapData
Because this is tiresome and bloats the code, if you start your .cs file with
using System.Drawing.Imaging;
you could then instantiate a class using just the name BitmapData.
This will be true only for the .cs file in which you added the using directive, not for the whole project.
Also, it's important to note that using one namespace does not bring in all nested namespaces, you have to using each one individually.
You must brush up on your your Google-fu
http://www.harding.edu/fmccown/java_csharp_comparison.html#namespaces
It can be called importing / referencing/ using namespace.
Such a language feature is not available in c#.
A little explanation: Namesspaces can be spread across multiple libraries. so when you use a namespace it may refer to it from multiple referenced assemblies.
It's called namespace and it's imported by a keyword using. For example:
using System;
This statement enables you to reference all the classes that exist in that namespace. They, however don't enable you to reference any class in the subnamespace of declared namespace. You have to declare each namespace separately. For example:
using System;
using System.Text;
Of course, you need to have a proper references added to the project where you're specifying the using directive.
Within .Net, you first would need to ensure that there is a referenced assembly containing the namespace you would like to import. Once that reference exists, you can use the 'using' directive to bring that namespace into the class so as to not have to fully qualify all object names. You can find more information on this directive on MSDN.
If I misunderstood, let me know and I'll do my best to get you pointed in the right direction.
I come from Java and see that package in Java is very convenient. When you move a class to another package, it will change automatically the package. (of course, by IDE such as Eclipse or Netbean)
But C# is using namespace and don't have my namespace renamed automatically like it does in Java. For example I have a file which namespace is com.app and I put it in com.app, but at later time, I move this file to com.lib folder and its namespace still be com.app. So, I find this is difficult to manage because I'm moving it manually.
Please give me help in how to fix my problem. (that namespace of file is named by folder it contains, and when I move to other, I will automatically change). Can we do it?
I fix the problem by using an IDE plugin called Resharper. (Among many, many useful features) it highlights when a namespace is wrong (based on the folder hierarchy and root namespace of the assembly) and can fix it for you.
Note that unlike in Java, there are sometimes very valid reasons for a class to be in a namespace other than the one inferred by the directory structure. A good example might be extension method classes, which need to be in scope in the class that is invoking them. Therefore it is common to have:
/myProject
/extensions
/MyExtensionMethodClass.cs
with a namespace like myProject (so that the extension methods can be used anywhere in myProject without a using directive)
Thats actually because C# has the concept of partial classes , that is , you can distribute your C# class along several files instead of just having it coded into a single file , like Java. For that reason , namespaces in .Net are distributed containers instead of centralized containers , defined by your namespace orperator.
On MSDN I can read what it does, but I would like to know what it does technically (tells compiler where to look for types..)? I mean using as a directive.
The primary function of the using directive is to make types within a namespace available without qualification to the user code. It considers the set of namespaces and types which are defined in referenced assemblies and the project being compiled.
Take for example the following definition in MyTypes.Dll
namespace MyTypes {
class Class1 {}
}
Now consider referencing MyTypes.dll from another project with a different namespace. Without a using directive to create Class1 i need to qualify the name
MyTypes.Class1 local1 = new MyTypes.Class1();
The using directive lets me remove this qualification
using MyTypes;
...
Class1 local1 = new Class1();
#JaredPar's answer is correct, however I'd like to add that it doesn't quite work the same way as say import in Java. (someone correct me if I'm wrong about Java's import actually importing it into memory)
You need to include either a DLL or project reference in order to even be able to use using however it's not loaded into memory until you actually call into a method/property/something in the assembly. So you could have using System.Linq; but if you don't actually use any Linq methods, the Linq assembly is never loaded. (I'm not 100% positive that Linq is in it's own physical assembly since namespaces and assemblies aren't 1:1, but for sake of example I'm assuming it is)
using informs the compiler which namespaces to search for names used in the file but not defined in the file.
using just tell the compiler to go to the assembly's configuration file and search for a specific DLL with the name given, if the DLL is found then it links that dll into the current project. using is just a link operation to have DLL talk to each other in a shared space in memory.
The guy below here is right