9

The C++ Standard says that "=" , "()" , "[]" should be non static member function.

Why it is specified in this way ? Why do we need to define standard in such a manner ?

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
Lalu Parshad
  • 109
  • 2
  • Just a guess: `operator[]` was supposed to be used for building more complex analogs of things like C's array, where only object semantics made sense. Ditto for `operator()`. Otherwise, yeah, it seems that it's an arbitrary decision, and there's no reason why in principle there couldn't be a class subscript, for example. – Ami Tavory Mar 04 '16 at 06:31
  • 1
    Hard to assign to an object without an object, and a static method has no backing object. – user4581301 Mar 04 '16 at 06:33
  • I can see why assignment wouldn't work, and [] is linked somewhat to the (this +) of pointer arithmetic, but I don't understand the restriction for (). Plus one. – Bathsheba Mar 04 '16 at 06:36
  • @user4581301 But a class can have static members, so, conceptually assigning to it, could mean assigning something to these class members. – Ami Tavory Mar 04 '16 at 06:37
  • @AmiTavory: Do you have an example of what you want to do? Or are you just questioning the wording of the specification? Typically, if you have an object you want to assign to, that is static, you can assign to it. – Mats Petersson Mar 04 '16 at 06:40
  • are you asking why they may not be static, or why they may not be non-members? – M.M Mar 04 '16 at 06:44
  • @MatsPetersson It's not exactly that I "want to do" it. My point, though, is that, conceptually, for a class `foo`, the language could have supported `foo = make_tuple(1, 2, 3)`, and the meaning would be that the static members of `foo` are somehow assigned by this (at the interpretation of `foo`'s author, as with every `operator=`). It *would* mean, though, that a class `operato=` takes an object and returns an object. – Ami Tavory Mar 04 '16 at 06:44
  • Do you have a reference to the place where this restriction is laid out in the standard? I cannot see any strong reason for any of those restrictions. – juanchopanza Mar 04 '16 at 06:45
  • @AmiTavory can't argue that. It would look weird, but I guess that's about the worst of it. – user4581301 Mar 04 '16 at 06:46
  • @user4581301 Non-member functions can also act on objects. So can statics member functions. – juanchopanza Mar 04 '16 at 06:56
  • @Bathsheba There's no reason assignment wouldn't work, except that the standard doesn't allow it. – juanchopanza Mar 04 '16 at 07:05
  • @juanchopanza: Hum. That doesn't help address my confusion. To my mind the thing you assign to is an "embedded *this", if you get my meaning. – Bathsheba Mar 04 '16 at 07:45
  • @Bathsheba I get your meaning, but it doesn' t *have* to be that way. Although Bo Persson points out that, with the compiler synthesizing `operator=` in many cases, it might be complicated to reconcile that with a non-member version defined elsewhere. – juanchopanza Mar 04 '16 at 09:05

1 Answers1

2

I don't know what the standards committee was thinking, but these operators aren't much use if they are not operating on the object itself.

You also get into trouble if "anything" can be used for operator() or operator[], since they are also used in conventional code. If you don't need an object to operate on [and thus select the correct operator through], it gets messy to figure out which operator[] to use.

The operator= is even more so: What are you assigning, if not an object? It makes absolutely no sense to do that on anything but an object.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227