Где выделенная ссылка на переменную в стеке или в "куче"?
Вы должны добавить ключевое слово template перед imp_f3, как вы это делали для T_Src::template imp_f1:
static_cast(this)->template imp_f3();
Посмотрите на этот вопрос для объяснение.
4 ответа
myShip - это ссылка на объект Ship , myShip находится в стеке вызовов методов, который называется «стек ». Когда метод вызывается, блок памяти помещается на вершину стека, в этом блоке памяти есть место для всех примитивов (int, float, boolean и т. Д.) И ссылок на объекты метода, который включает параметры метода. Куча - это место, где выделяется память для фактических объектов.
Итак, myShip находится в стеке, а объект Ship - в куче.
Обратите внимание, что каждый поток имеет свой собственный стек, но совместно использует кучу.
Java really does things a bit differently. The reference is basically on the stack. The memory for the object is allocated in what passes for the heap. However, the implementation of allocable memory isn't quite like the way the heap is implemented in the C/C++ model.
When you create a new object like that, it effectively puts the name into the table of references for that scope. That's much like a pointer to an object in C++. When it goes out of scope, that reference is lost; the allocated memory is no longer referenced, and can be garbage-collected.
Условно объект идет на "кучу". Затем, поскольку это ссылка на локальный метод, фактическая ссылка будет в стеке. Под «стеком» мы подразумеваем стек собственных потоков (то есть тот же стек, в котором будет размещена локальная переменная в C), по крайней мере, в случае виртуальной машины Sun, но я не думаю, что это на самом деле требование (JVM просто нужно иметь какое-то абстрактное понятие «кадры стека», которые он выделяет при каждом вызове метода, будь то из собственного стека или нет).
Но ... на современных виртуальных машинах (с возможным исключением более простых встроенных / мобильных виртуальных машин) действительно нет такой вещи, как «куча». На практике существуют различные области кучи. The simplest of these is typically almost like a "mini stack", designed to be quick to allocate for objects that won't hang around for long and can probably be de-allocated almost at once.
As mentioned by another poster, a highly optimised JVM could in principle allocate object data on the stack and there are definite proposals for this. Although, as also mentioned in one of the references, a criticism of this is that the fast "eden" heap is almost like a stack anyway (just not "the" stack).
Currently, all Java objects are allocated on the heap. There is talk that Java 7 might do escape analysis and be able to allocate on the stack, but I don't know if the proposal is finalized yet. Here's the RFE.
Edit: Apparently, it's already in early builds of JDK 7. (The article says it will also be in JDK 6u14, but I can't find confirmation.)