3

I can't think of a case when using :: to specify a scope would result in any code being generated. Every other operator I can think of actually (at least conceptually) generates code, it 'does something'.

So why is :: called the 'scope resolution operator' when it in no way behaves like an operator. It seems more to me like part of a name, a bit of lexical fluff like ... or the < and > surrounding a template parameter list, or even ;. Nobody calls ; the 'expression termination operator'.

Is there a specific reason it's called that (a quote from the standard on how it somehow behaves like an operator would be in order here)? Or is the name just historical baggage?

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
  • 6
    "Every other operator I can think of actually (at least conceptually) generates code" - how about `sizeof`? The `::` operator is an operator because the language grammar says it is. –  Jul 05 '18 at 19:52
  • 3
    What else would you call it? The "scope resolution lexical fluffer" doesn't carry as much weight. – zero298 Jul 05 '18 at 19:53
  • You can think of a namespace as an object, and `::` allowing you to select types and other namespaces inside it. In that sense it is an "operator" of the type-system, rather than of objects/values. – Horia Coman Jul 05 '18 at 19:54
  • A somewhat semantic discussion. I suppose they could have called it a qualifier instead. Some other languages use that term in similar contexts. – 500 - Internal Server Error Jul 05 '18 at 19:54
  • @zero298 - Scope name separator? – Omnifarious Jul 05 '18 at 19:54
  • 3
    I don't think separator would be correct. It doesn't separate, it implies nested membership. It would be closer to the `.` or `->` symbols which are also called "operators". – zero298 Jul 05 '18 at 19:58
  • @zero298: My thoughts exactly! – Bathsheba Jul 05 '18 at 20:01
  • 1
    @Downvoters Please enlighten us on how this question does not show any research effort, is unclear, or is not useful? – Bathsheba Jul 05 '18 at 20:18
  • And nobody talks about `operator ,` :-/ – Jarod42 Jul 05 '18 at 20:30
  • @Jarod42 - I was thinking about that one. I'm not sure if it's overloadable or not. It shouldn't be, just like `operator &&` and `operator ||` shouldn't be. They're sequence points, and allowing them to be overloaded breaks that. And the sequence point property is too important for it to require knowing if you're using it in an overloaded context or not. But, I would consider it an operator, sort of like `progn` in lisp. I guess because it's part of an expression that has a value. – Omnifarious Jul 05 '18 at 20:32
  • @Omnifarious Yes, it is overloadable, as a minutes research would have told you. It seems to me you posted this question without doing any research in advance at all. –  Jul 05 '18 at 20:54
  • @Bathsheba I see no evidence of research at all. And I don't think it is useful. –  Jul 05 '18 at 21:00
  • @NeilButterworth: Fair enough. – Bathsheba Jul 05 '18 at 21:02
  • @NeilButterworth - If I had taken it upon myself to ask if the `,` operator were overloadable, I would've taken the time to look it up. As it was, it wasn't important for the comment I posted because regardless of whether or not it is overloadable, it shouldn't be. – Omnifarious Jul 05 '18 at 21:09
  • 1
    The example with `;` is an interesting case. However, in C++ and most other languages (one exception is Pascal) it is not an expression *separator*. It is an expression *terminator*. – klutt Jul 05 '18 at 22:38

3 Answers3

8

But it is an operator, as much as say the member selection operator .:

#include <iostream>
int n;
int main()
{
    int n = 1;
    std::cout << ::n << " " << n;
}

and

#include <iostream>
struct N {
    int n = 1;
    operator int() const {return 0;}
};
int main()
{
    N n;
    std::cout << n << " " << n.n;
}

The output is the same in both cases.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • You and Nicol Bolas combined have a really interesting point. All of the operators you both mention aren't overloadable. And you're example of the member selection operator is an excellent one. It is very like the scope resolution operator in a lot of ways. – Omnifarious Jul 05 '18 at 20:02
  • 1
    @Omnifarious: If Stroustrup gets his way, the member selection operator *will* be overloadable. – Bathsheba Jul 05 '18 at 20:02
  • Yeah. I know there are proposal to make it overloadable. I don't like the idea much though. :-/ – Omnifarious Jul 05 '18 at 20:05
  • 1
    @Omnifarious: Indeed, I hope I will have retired by then. – Bathsheba Jul 05 '18 at 20:05
  • The member resolution operator is such a good example, and the fact that someone has at least conceived of overloading it, makes it clearer why `::` is an operator than anything else anybody has brought up. – Omnifarious Jul 05 '18 at 20:12
3

Operators in C or C++ are not required to generate code. Operators which do not include, but are not limited to, sizeof, alignof, and even some uses of & (such as for types which decay to pointers).

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • I like this answer, but one way I would distinguish `sizeof` and `alignof` is that they are expressions that have values. Though, thinking of it this way, the scope resolution operator is sort of like that. – Omnifarious Jul 05 '18 at 19:56
  • I just noticed an interesting thing. None of the operators being mentioned are overloadable. – Omnifarious Jul 05 '18 at 20:03
  • @Omnifarious: Indeed. `::`, `->`, and `.` all, in a sense, identify an object. – Bathsheba Jul 05 '18 at 20:04
  • 1
    @Omnifarious: Well, `&` is overloadable, but I think we all wish it weren't. Also `->` is overloadable, and some people even want `.` to be overloadable. – Nicol Bolas Jul 05 '18 at 20:05
  • 1
    Also, I don't think `->` is such a great example because in C it's exactly equivalent to `(*thing).member`, and pointer dereference is most certainly an operator. And, in fact, the only real functionality in `->` that can be overloaded is the pointer dereference part. I might even prefer the language definition to be changed so `->` can't be overloaded, but is defined in terms of the overloaded `operator *()` if it exists. – Omnifarious Jul 05 '18 at 20:20
2

In case you are specfically concerned about the term 'scope', it referes to a declaration(definition scope). A statement block - enclosed in curly braces - defines a declaration scope too. No identifier can be accessed outside its declaration scope unless the actual scope is properly resolved. Identifiers nested in unnamed scopes (eg. statement blocks) are buried in their definition scope forever. But identifiers in name scopes can be reference from outside via chaining of nesting scopes respectively, by means the 'scope resolution operator'. It is called an operator because it operates on 2(or 1) identifiers in order to result in a compile-time referential binding. Compare it to the member-access (the dot) operator that creates a callable binding. And please do not open the door towards hermeneutics, we are not practising philosophy in this forum.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
Red.Wave
  • 2,790
  • 11
  • 17
  • You mean '*hermaneutics*'? And I think talking about why things are named the way they are is interesting and useful. Names and categories are the pegs on which thought is hung. Thinking about why something is named as if it were in a given category helps in understanding the language more fully and assists in the creation of useful new ideas and concepts. – Omnifarious Jul 05 '18 at 20:30
  • The naming is deep problem. Prime concepts do not have any definitions, but every other definition depends on them. prime concepts may be discribed but in noway defined. Operators - in the context of C++ - are kinda prime concepts. and since english is not my first language - ie. the one that I learned logics in - I should apologize if the terms I pick are not the exact ones. Again this is not a philosophy forum. – Red.Wave Jul 05 '18 at 20:52
  • Or spelling ;-) – Bathsheba Jul 05 '18 at 20:57
  • @Bathsheba Don't giggle. I am fluent in 5 languages, C++ being the 2nd. English comes next. – Red.Wave Jul 08 '18 at 11:48