Globals resolution?

[Catfish3]

Do you consider it ugly to put :: in front of global variables and functions?

namespace {

int global;

int f(int i)
{
    return i;
}

} // namespace

int main()
{
    return ::f(::global);
}

[chrisname]

Yeah, I see :: as connecting two things so if you put ::ident it's like you're connecting it to the void. I don't like it.

[LB]

I would prefer it when it could potentially be ambiguous.

@chrisname I see it as the scope resolution operator, not as connecting two things. I think of it as resolving the scope when it is ambiguous or not clear.

[chrisname]

No need to be passive aggressive.

[zb0S216C]

You've just made everything within the name-space static; you won't be able to access them outside of the TU. Was that intentional? I personally don't think it was or else you would've said.

As for the actual question, yes, I only use the SRO prefix when my code is within the global name-space. However, 99% of the time my code resides within a user-defined name-space so I tend to omit the SRO prefix. And no, it's not ugly; it's explicit and I like that.

+1 LB for mentioning ambiguity resolutions.

_Wazzak

[Oria]

I would of preffered a .

[zb0S216C]

@Oria: Please explain why the member-access operator would be preferable.

_Wazzak

[chrisname]

@Framework
He knows C# so I'm guessing it's because C# uses the . operator for both member access and scope resolution. Like me, he probably prefers how it looks.

[zb0S216C]

Ah, right. Strange answer though, for a C++ question.

_Wazzak

[Oria]

He knows C# so I'm guessing it's because C# uses the . operator for both member access and scope resolution. Like me, he probably prefers how it looks.

Exactly. I find that it looks cleaner.

Ah, right. Strange answer though, for a C++ question.

Well he ask if we think its ugly... in short answer; I do.

Edit:

in reality C# is designed differently for that though. because everything has to be inside a namespace, so let say your namespace is Joe; your global variable would be Joe.global

[chrisname]

Oria wrote:

everything has to be inside a namespace

Nothing has to be inside a namespace. You can write a C# program without the word "namespace" appearing anywhere. You just can't put variables and methods outside of a class.

[LB]

::Namespace::Class::StaticMember(OrFunction).InstanceFunction().InstanceMember.InstanceFunction();

I like being able to tell the difference between instance and static. I hate that you can use the . operator to access static fields, I wish that would go away.

[chrisname]

You mean like this?
if (string.find(search) != string.npos)
? Because I hate that too (using an instance to access a static member, that is).

[LB]

I wouldn't mind InstanceVariable::StaticMember, but then you would get me fussed up about how static class functions should be polymorphic when called from an instance.

[chrisname]

IMO static members should only be referencable from a static context, i.e. Class::Member or Class.Member.

[LB]

I would prefer a different syntax from accessing members so that an ugly naming convention wouldn't have to be used.

[maeriden]

What would you use?

[LB]

:: for static
. for instance

[Oria]

Nothing has to be inside a namespace. You can write a C# program without the word "namespace" appearing anywhere. You just can't put variables and methods outside of a class.

Right sorry, inside the class is what I meant, out side of the methods.

However I didn't know you didn't need a namespace. I guess I've never tried to not use one, but I just tested it and yeah, no namespace needed...

[chrisname]

@L B
What ugly naming convention?