"global::" usage

[twang090]

I find in other team member's project, they are referencing a type in
following format
"
public static global::ErrorReport.Description Description
= new global::ErrorReport.Description();
"

I do not understand the usage of "global" here, could anyone please
clarify its usage and what benift of using that. Thanks in advance.

 

[Nicholas Paldino [.NET/C# MVP]]

In C#, you can have namespaces and classes which share a name as well as
have nested namespaces/classes which have are shared, causing ambiguity.

Using "global::" indicates that the namespace after it will be processed
from the root level, not using the immediate namespace/class scope for
resolution.

 

[kentcb]

See http://msdn2.microsoft.com/en-us/library/c3ay4x3d(VS.80).aspx. You
will often see the global:: qualifier in generated code to ensure that
it is refering to the correct types. I don't think I've ever since it
used manually - it's rarely necessary. It's unclear from your example
whether it is actually needed or not. It depends whether there are
more than one ErrorReport types.

Regards,
Kent

 

[Stoitcho Goutsev \(100\)]

In c# you cannot create a class that does not belong to a namespace, however
in some other languages such as IL and I blieve C++ and VB.NET you can. the
*global* scope has been added to C# 2.0 in order to solve the problems where
programmers have ran accross such assemblies containing types declared
outside any namespace.

 

[Jon Skeet [C# MVP]]

In c# you cannot create a class that does not belong to a namespace, however
in some other languages such as IL and I blieve C++ and VB.NET you can. the
*global* scope has been added to C# 2.0 in order to solve the problems where
programmers have ran accross such assemblies containing types declared
outside any namespace.

In C# you can create a class which doesn't have any declared namespace
- just don't use a namespace declaration. Is there a difference between
that and the kind of class you can create in C++ or VB.NET?

 

[Nicholas Paldino [.NET/C# MVP]]

Stoitcho,

That's not true. It was meant for the following example:

namespace Acme
{
public class MyClass {}
}


namespace MySystem
{
public class Acme
{
public class MyClass {}
}

public class MyOtherClass
{
public Acme.MyClass MyAcmeClass;
}
}

In the example above, the compiler would always resolve the MyAcmeClass
to the type MySystem.Acme.MyClass. If you wanted it to be Acme.MyClass,
there was no way to do it until C# 2.0. In C# 2.0, you would use:

public class MyOtherClass
{
public global::Acme.MyClass MyAcmeClass;
}

To indicate that you shouldn't use the local namespace scope, but
rather, the root namespace.

While the other cases might be true, the primary reason was for the
above case (I was there when the C# team presented this feature to a closed
customer council).

 

[Guest]

Is there a difference between
that and the kind of class you can create in C++ or VB.NET?

The VB language supports classes at the global scope; but the VB.NET IDE
does not; you must specific a default namespace for a project in which all
classes and namespaces will be nested. I don't know what the global scope
resolution operator/keyword is in VB...

In C++/CLI you can also have managed classes at global scope. In C++ the
global scope resolution operator is '::', the equivalent of 'global::'. But,
often Intellisense gets confused with that...

 

[Mattias Sjögren]

The VB language supports classes at the global scope; but the VB.NET IDE

does not; you must specific a default namespace for a project in which all
classes and namespaces will be nested.

You don't have to specify one, you can leave it blank.


Mattias

 

[Guest]

I've had it complain that the root namespace can't be empty. But, with some
projects it does let you have an empty namespace. Interesting...

 

[Guest]

It appears you can't have an empty root namespace for class library projects
in VB, but you can for Console/Winform applications. Interesting...

 

[Guest]

I'm not sure what's different, but I have some VB class library projects not
allow a blank root namespace and some do. Interesting...

I'll add that to my list of reasons why I don't like VB...

 

[Stoitcho Goutsev \(100\)]

Thanks Nicholas and all others,

for the clarifications. Indeed my statemement wasn't right.

Regards,
Stoitcho Goutsev (100)

Stoitcho,

That's not true. It was meant for the following example:

namespace Acme
{
public class MyClass {}
}


namespace MySystem
{
public class Acme
{
public class MyClass {}
}

public class MyOtherClass
{
public Acme.MyClass MyAcmeClass;
}
}

In the example above, the compiler would always resolve the MyAcmeClass
to the type MySystem.Acme.MyClass. If you wanted it to be Acme.MyClass,
there was no way to do it until C# 2.0. In C# 2.0, you would use:

public class MyOtherClass
{
public global::Acme.MyClass MyAcmeClass;
}

To indicate that you shouldn't use the local namespace scope, but
rather, the root namespace.

While the other cases might be true, the primary reason was for the
above case (I was there when the C# team presented this feature to a
closed customer council).