I always call it the "arrow operator", but I'm sure it has an official name. I quickly skimmed the C++ standard and didn't see it mentioned by name.
The C++ standard just calls it "arrow" (§5.2.5).
Bjarne Stroustrup calls it the "structure pointer dereference" operator (TC++PL Special Edition, p. 102). In the index he refers to it as the "member access" operator.
Not sure if this is "official" but the guy did write the language, after all.
The official name for this operator is class member access operator (see 5.2.5). Although this name is attached to both . and -> operators, meaning that it's more of a group name. The . is also referred to as dot operator and -> as arrow operator in the standard text.
Added later: The above applies to C++ standard. C standard refers to -> as arrow operator in the Index only. The main text of the document doesn't seem to use any specific name.
According to Wikipedia's list of operators in C and C++, it's called "member by pointer".
But to be totally honest, I've always called it "arrow". For example, if I had the code a->b, I would read that as "a arrow b".
Its just the dit (ie not dot).
These terms are in no way official, but I'd call the dot operator the direct (class) member access operator and the arrow operator the indirect (class) member access operator to clarify their relationship with the indirection operator.
I've heard it referred to a few different ways, was never sure any one in particular was more official than another.
Member Selection Operator
Pointer Dereferencing Operator
"the arrow thingy"
and I'm sure there are others. personally I'm less concerned about what its called in a book or an official spec and more concerned that people know what I mean when I refer to it, so in my opinion "arrow thingy" is the best name for it since its the easiest to understand clearly what is being referred to.
The index to ISO/IEC 9899:1999 (the C99 standard) has three index entries for 'arrow operator' (in its own right, and under 'union' and 'struct'), and refers to section 6.5.2.3 (Structure and union members, in the section on Postfix operators). However, there is no mention of 'arrow' in section 6.5.2.3 or anywhere else in the standard than the index (every other appearance of 'arrow' is as part of 'narrow' or a derivative of narrow).
Arrow is therefore semi-officially sanctioned in the C standard (the index is not normative or standard setting, though).
Dereference Pointer
There was a recent question regarding how the operator is "pronounced" in context.
Consider the multiplication operator which is pronounced "times" in context.
I consider both member access operators {. ->} to indicate possession so I pronounce them as a possessive on the object.
For example...
fido->collar()
...would be pronounced as "fido's collar".
On the other hand possession isn't appropriate for verbs so...
fido->run()
...would be pronounced as "fido runs".
The ISO C standard calls it the->operator or the member-access->operator. So apparently it does not have an "official" name in C.
Personally, I just say pointer or arrow.
Related
Im curious if they have an official name or just 'dot' and 'arrow'? I try search this in cpluscplus and in Deitel, but didn't find anything
The C standard calls them member access operators, but only in the index. They aren't given a name anywhere else except the one place in the index. In the same place, the -> operator is called arrow operator, the . operator is called structure/union member operator.
According to my preferred (C++) reference they are called Member Access operators.
But to distinguish one from the other these are usually called dot and arrow operator (see the link #AnT mentioned in their comment).
The term "method" is often used to discuss C++ code. Does the standalone term have a well-defined meaning in C++ or is it ambiguous? Is it acceptable to use the term by itself, or should it be qualified (e.g. a "class method" or "virtual method"), or should it be simply avoided altogether?
The term method is not defined in the C++ standard. The terminology uses member function instead.
Bjarne Stroustrup however defines the term method in his own glossary as virtual member function. So this shows evidence that the term is acceptable.
I would avoid this term entirely, as it is clear what you mean by "member function", but not "method" - that you asked this question is proof enough.
However, normative appearances of the word "method" in the C++14 standard are
In the content list:
17.5 Method of description (Informative)
This is repeated in the title of that section.
[basic.compound]:
These methods of constructing types can be applied recursively;
[cpp.include]
The method by which a sequence
of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined
into a single header name preprocessing token is implementation-defined.
[library.general]
The following subclauses describe the definitions (17.3), method of description (17.5), [..]
In table 32, FLT_EVAL_METHOD is mentioned.
In stage 2 of num_get's do_get:
For arithmetic types, punct.thousands_sep() characters are inserted
into the sequence as determined by the value returned by
punct.do_grouping() using the method described in 22.4.3.1.2
[forwardlist.modifiers]:
Otherwise, inserts sz - distance(begin(), end()) elements at the end of
the list such that each new element, e, is initialized by a method equivalent to calling allocator_traits<allocator_type>::construct(get_allocator(), std::addressof(e), c).
[filebuf.virtuals]:
Behaves according to the description of
basic_streambuf<charT,traits>::uflow(), with the specialization that a
sequence of characters is read from the input with the same method as
used by underflow.
The term is clearly never referring to a "member function".
The C++ standard makes no mention of the term method. It should be noted that the official C++ FAQ does make use of this term, but to describe a virtual function; a simple Google search reveals more occurrences of this term.
I've never seen the term method in an IDE (Visual Studio), but I've seen the term member function. In my opinion method is a 'one size fits all' term.
The term method had been historically used as a synonym of the procedure of an object. Considering, an object has both data and behaviour, it is this behaviour which was referred as method.
Tracing backward, I could find a reference to the usage of the term method when referring to an MIT ALGOL version, AED-0
Quoting wikipedia
MIT ALGOL version, AED-0, linked data structures ("plexes", in that
dialect) directly with procedures, prefiguring what were later termed
"messages", "methods", and "member functions".
Over the years method had been an integral part of Object Oriented Analysis and Design and Object-oriented programming. Now C++ evolved as a procedural language where it extended C a procedural language to have object oriented capabilities. C had the concept of structure, and the data elements were called members. Refer Methods in C++.
To not break the lineage, C++ continued to call the elements of structured and the newer genre class as members.
Now, to differentiate between data and functions, instead of introducing a new terminology, it extended this terminology to call data members and member functions. Member functions which supported dynamic binding were called virtual functions.
So, strictly speaking, official references refrains from using the terminology methods when referring to member functions. The terminology is most prevalent among the people who have a more Object Oriented background. So if you want to remain unambiguous, it is best to use the terminology as
data member
member function
virtual functions
Here my analysis regarding the word method.
I did a scan on official documentation (standards, specifications, etc.) on several programming languages.
http://componentsprogramming.com/using-the-right-terms-method/
Adequate taxonomy (not dependent on any programming languages) will be published in a future article.
Regarding to C++, the correct terminology is: member/non-member function.
Some people use member/free functions.
My C++ teacher thinks that the * operator in standard C++ is "already overloaded," because it can mean indirection or multiplication depending on the context. He got this from C++ Primer Plus, which states:
Actually, many C++ (and C) operators already are overloaded. For example, the * operator, when applied to an address, yields the value stored at that address. But applying * to two numbers yields the product of the values. C++ uses the number and type of operands to decide which action to take. (pg 502, 5th ed)
At least one other textbook says much the same. So far as I can tell, this is not true; unary * is a different operator from binary *, and the mechanism by which the compiler disambiguates them has nothing to do with operator overloading.
Who is right?
Both are right as the question depends on context and the meaning of the word overloading.
"Overloading" can take a common meaning of "same symbol, different meaning" and allow all uses of "*" including indirection and multiplication, and any user-defined behavior.
"Overloading" can be used to apply to C++'s official operator overloading functionality, in which case indirection and multiplication are indeed different.
ADDENDUM: See Steve's comment below, on "operator overoading" versues "token overloading".
I believe you are. The dereference op and the mult. op are different operators, even if written the same. same goes for +,-,++,--, and any other I may have forgotten.
I believe the book, in this paragraph, refers to the word "overloaded" as "used in more than 1 way", but not by the user. So you could also consider the book as being correct... also depends if you're referring to the overloading of the * operator or of the multiplication operator (for example).
It's overloaded in the sense that the same character is used to mean different things in different places (e.g. pointer dereference, multiplication between ints, multiplication with other built-in types, etc.).
Generally, though, "operator overloading" refers to defining an operator (that has the same symbol as a built-in one) using custom code so that it does something interesting with a user defined type.
So... you're both right :-)
The C++ standard defines the expression using subscripts as a postfix expression. AFAIK, this operator always takes two arguments (the first is the pointer to T and the other is the enum or integral type). Hence it should qualify as a binary operator.
However MSDN and IBM does not list it as a binary operator.
So the question is, what is subscript operator? Is it unary or binary? For sure, it is not unary as it is not mentioned in $5.3 (at least straigt away).
What does it mean when the Standard mentions it's usage in the context of postfix expression?
I'd tend to agree with you in that operator[] is a binary operator in the strictest sense, since it does take two arguments: a (possibly implicit) reference to an object, and a value of some other type (not necessarily enumerated or integral). However, since it is a bracketing operator, you might say that the sequence of tokens [x], where x might be any valid subscript-expression, qualifies as a postfix unary operator in an abstract sense; think currying.
Also, you cannot overload a global operator[](const C&, size_t), for example. The compiler complains that operator[] must be a nonstatic member function.
You are correct that operator[] is a binary operator but it is special in that it must also be a member function.
Similar to operator()
You can read up on postfix expressions here
I just found an interesting article about operator[] and postfix expression, here
I think it's the context that [] is used in that counts. Section 5.2.1 the symbol [] is used in the context of a postfix expression that is 'is identical (by definition) to *((E1)+(E2))'. In this context, [] isn't an operator. In section 13.5.5 its used to mean the subscripting operator. In this case it's an operator that takes one argument. For example, if I wrote:
x = a[2];
It's not necessarily the case that the above statement evaluates to:
x = *(a + 2);
because 'a' might be an object. If a is an object type then in this context, [] is used as an subscript operator.
Anyway that's the best explanation I can derive from the standard that resolves apparent contradictions.
If you take a close look to http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B it will explain you that standard C++ recognize operator[] to be a binary operator, as you said.
Operator[] is, generally speaking, binary, and, despite there is the possibility to make it unary, it should always be used as binary inside a class, even because it has no sense outside a class.
It is well explained in the link I provided you...
Notice that sometimes many programmers overload operators without think too much about what they are doing, sometimes overloading them in an incorrect manner; the compiler is ease is this and accept it, but, probably, it was not the correct way to overload that operator.
Following guides like the one I provided you, is a good way to do things in the correct manner.
So, always beware examples where operators are overloaded without a good practice (out of standard), refer, first to the standard methods, and use those examples that are compliant to them.
you probably have been tought, are tought yourselves, that . and -> are operators which retrieve members of a struct (C) or class (C++).
However, I doubt they are operators - because, if they are operators, what are their input types? Furthermore, the identifiers on both sides are interdependent - a feature which for example the + operator lacks of.
If this is correct - in what sense are these still labeled as operator in practice, and what is their formal definition with regard to language theory.
You assume that the only types which can be passed as arguments to an operator are types that can be defined within the language.
I would argue that any type which can be recognised by the compiler may be passed as an argument, including internal types such as "identifier". The operator will have two arguments in its AST representation, which is enough to allow you to define semantics.
Another argument is that language theory may provide one set of definitions for your vocabulary, but it isn't the only one.
For example, an operator may be a man who works a machine. That definition has no relevance to programming theory, but it won't stop me using for keywords in a domain-specific language expressing something to do with machine operating. Similarly, the term "operator" has a wider definition in mathematics than that which is specific to programming theory - and that definition isn't invalidated simply by working with a programming language.
To put it another way - if you didn't call it an operator, what would you call it?
EDIT
To clarify, my first argument is referring to the syntax for using the operator (the call). These operators have right arguments which are identifiers - member names - which the C++ language cannot express using a data type. The C++ language does have member pointers, but they aren't the same thing as the members - just as a variable isn't the same as a pointer to that variable.
I assume that is what the question referred to. The right parameter of those operators has a type which cannot be expressed or manipulated normally in the language.
What happens when that syntax is mapped to an overloaded operator-> function is a different thing. The function isn't the operator - it's only how the operator gets implemented.
I think the fact that you can overload the -> operator using the "operator" keyword should be a dead giveaway.
Smart pointers do it pretty often:
template<class T>
struct myPtr {
T *operator ->() { return m_ptr; }
private:
T *m_ptr;
};
The . is not overloadable, but is also an operator by definition.
Hmmm...sizeof is an operator, what is its input type? I don't think the question is useful for distinguishing operators from non-operators in this context.
And that would be because what "operator" means in the context of a programming language is exactly what the author of the language says it means. Shades of Lewis Carroll here.
This reference says they're both operators in C++:
http://www.cplusplus.com/doc/tutorial/operators/
Is that not authoritative enough?
You can overload the -> operator: Wikipedia. That page also states that you can't overload dot. There's an example of -> overloading here:
class String // this is handle
{
...
Stringrep *operator -> () const { return b_; }
private:
Stringrep *b_;
}
The arrow works on the value to the left of the arrow and returns whatever the left hand side is "holding inside". Think of a smart pointer.
THe C++03 standard refers to both as operators.
Example:
...after the . operator applied to an expression of the type of its class...
If you are not comfortable with that terminology you can use the term punctuator for ..
Online C standard (n1256):
6.5.2.3 Structure and union members
Constraints
1 The first operand of the . operator shall have a qualified or unqualified structure or union
type, and the second operand shall name a member of that type.
2 The first operand of the -> operator shall have type ‘‘pointer to qualified or unqualified
structure’’ or ‘‘pointer to qualified or unqualified union’’, and the second operand shall
name a member of the type pointed to.
They are operators, and their input types are specified by the standard.
haha, i know people have already said this in a roundabout way but just to say it directly. In C terms, label-> is actually a shorthand for (*label). .That being said, . is the operator which references elements in a struct. Therefore, -> references an element in a pointer to a struct.