:: is a scoping operator, not related to memory layout

[jaynabonne]

Technically speaking, the use of “::” in C++ is to resolve scope within a class, namespace or enum. It has nothing to do with memory layout. For example, if you have a namespace with a class inside it, you would use the scoping operator to access it. But the class within the namespace has no actual storage anywhere. The same goes for an enum. The definition of an enum has no physical storage. But you can use the scope operator to “tunnel” down into it. Similarly, you can have nested types within classes which are strictly related to defining types, but they have no physical storage at runtime.

The “::” operator has nothing to do with storage. What you specify may have storage, but that’s not determined by the scope operator itself.

Also, though it doesn’t quite say that and could be interpreted the proper way, the table is laid out in such a way that it could be inferred that the “.” operator is used for stack memory and the “->” for dynamic memory, but there is no correlation. A reference or pointer could refer or point to either type of memory.

[jaynabonne]

To follow up on my last point about the “.” and “->” operators, there is no correlation between them and their storage either. You can actually have global objects (either at true global scope, static or within anonymous namespaces), which are neither on the stack nor in heap memory. But you still reference them the same way (either with “.” or “->” depending). So even for these operators, nothing about the storage class of an object can be inferred.

As an example, any sort of object can be passed to a function: global, automatic or dynamically allocated. It’s not possible to determine the storage type from within the function using any language features, regardless of whether the object is passed by reference or via a pointer. It could have come from anywhere.

I’m not trying to be pedantic or picky here. These are fundamental concepts, and if they’re made out to be something they’re not, then it might be useful in the short term, but it’s only going to be confusing (and have to be “unlearned”) later if the language is pursued further.

For example, did you know you can convert back and forth between a pointer and a reference (assuming the pointer is not null)?

Object o;
o.member = 1;

Object* o_pointer = &o;
o_pointer->member = 2; // o.member is now 2

Object* o_pointer2 = new Object;
o_pointer2->member = 1;

Object& o2 = *o_pointer2;
o2.member = 2; // o_pointer2->member is now 2

These are different ways to refer to objects, but there is no correlation between their usage and where an object comes from.

Third example:

Object global_object;

int main()
{
global_object.member = 1;
}

In this case, we have a global object (so known at compile time and neither on the stack nor in heap) which is referred to exactly the same as if it were on the stack or via reference. It is stored in the global data segment and initialized at run time.

[Michele_Caletti]

Completely agree, i was going to post to highlight just the same. The distinction proposed in the lesson is misleading and has no support in the actual language. The correct way to state things are in fact:

:: scope resolution operator. the purpose is to “resolve”, “give context” so that the compiler knows exactly what are you referencing. For example, you might have two classes with the same “grab” method, adding the :: tells exactly who’s who. It resolves ambiguities (and so it’s sometimes mandatory). It has nothing to do with object instances, by the way, and refers to names and their scope.

. operator: member access. It can access the member variables/methods, used on objects or references, so actual instances.

-> pointer “arrow” operator: it’s used for the same of the above, with a difference: it’s used only on pointers. So, deals with instances again.

to add to the argument, you can have static member objects or pointers. These go into a dedicated memory area, that’s known and resolved at compile time (well, link time). A static member doesn’t go in the stack or heap, so.