Якби мої методи повертали оригінали вказівників (використовуючи &), як тут:

class Node {
private:
    Node *next;
public:
    virtual Node *const &GetNext() const { return next; }
};
class DualNode : private Node {
private:
    DualNode *prev;
public:
    virtual DualNode *const &GetNext() const { return static_cast<DualNode *>(Node::GetNext()); }
    virtual DualNode *const &GetPrev() const { return prev; }
};
class ExtendedNode : private DualNode {
public:
    virtual ExtendedNode *const &GetNext() const { return static_cast<ExtendedNode *>(DualNode::GetNext()); }
    virtual ExtendedNode *const &GetPrev() const { return static_cast<ExtendedNode *>(DualNode::GetPrev()); }
};

тоді так. Але вони повертають копії.
Крім того хочу звернути вашу увагу на те, що компілятор не свариться на методи DualNode::GetNext() і ExtendedNode::GetPrev() (з коду наведеного в першому повідомленні), хоча якщо слідувати за вашою логікою, то мав би.

Але вся фішка якраз в тому, щоб клієнт не парився з моїм кодом і не приводив типи самотужки. Та все ж обдумаю вашу пропозицію.

Також рекомендую переглянути файли з архіву (їх всього 3), бо там випливають всякі нюанси, які не дають мені так просто переробити типи.

leofun01

Я не впевнений, але мені здається що тут було б доцільно NVI застосувати. Взагалі, ви якось по-збоченному використовуєте поліморфізм

Щоб їх можна було перевизначити, звичайно. Вузли мають різну поведінку зв'язування.
Якщо хтось візьме DualNode і запхає його в Node, то поводитись він має як DualNode.
Це якщо про Get/Set-Next/Prev.

Ну і поведінка відправки даних теж має бути загалом різною.

NVI - благородна задумка, але мені майже нічого не вдалося з нього вижати.
Зато появився новий файл (в архіві).

- тоді раджу проаналізувати код нижче, ну як допоміг статік каст, чи може нашкодив?Я і писав про те що все надійніше перевіряти у рантаймі, статіком первіряють те що не підходіть під динамічне віділення, а наява поінтеров у ваших класах вже говорить про те що виділення будут динамічними, ніякий статік вам там не допоможе.

#include <iostream>
using namespace std;
 
class Node {
private:
    Node *next;
public:
    virtual const Node * GetNext() const { return next; }
};
class DualNode : public Node {
private:
    DualNode *prev;
public:
    virtual const DualNode * GetNext() const{ return dynamic_cast< DualNode *>(const_cast< Node *>(Node::GetNext())); }
    virtual const DualNode * GetPrev() const{ return prev; }
};

int main(){
    Node *nodeArr[2] = {0};
    long *pointer    = new long;
    nodeArr[0] = new Node;
    nodeArr[1] = static_cast< Node *>((Node *)pointer);
    return 0;
}

http://codepad.org/hiVWiPpp

- VisualStudio навіть остання має деякі відмінності від компілятору у стандарті, я подаю лінки на те що більш менш відповідає С++0х

- я вам не обсудити писав, а писав що треба виключати, почитайте ресурси о приватному наслідуванні, певен зрозумієте.

- та ні взагалі то у контейнерах розробник повинен передбачити усе, у вас там у коді я бачив додавання данних через поінтер якийсь SetData(Node *val) - щось таке, а якщо користувач "всуне" туде якусь фігню?Чому програма повинна вилітати тільки тому що розробник не захотів динамічно кастувати?А якщо совтина дуже важлива, що такий фактор як тупий юзер(чи кодер, що буде юзати ваші класи далі) повинен впливати на стабільність?

- не треба читати все що пишуть на стінах та парканах. Уявіть собі ситуацію коли знадобиться доступ до якихось приватних змінних чи методів у класах потомках, що буде робити програміст - ліпити нові set/get у базовий клас, а якщо класс зібраний під лібу, тобто декларації є а код вже у lib файлі? Я дуже часто стикався з таким. Найкращій варіант public наслідування - все зостається таким яким воно є.

Ну з самого початку проблема звучала так:
Як мені залишити private-наслідування, virtual-const-функції, і позбутися помилки ?
Коли я писав, що рішення близько, то думав, що мені допоможе using. Наприклад:

class Node {
private:
    Node *next;
public:
    virtual Node *const GetNext() const { return next; }
};
class DualNode : private Node {
private:
    DualNode *prev;
protected:
    using Node::GetNext;
public:
    virtual DualNode *const GetNext() const { return static_cast<DualNode *>(Node::GetNext()); }
    virtual DualNode *const GetPrev() const { return prev; }
};
class ExtendedNode : private DualNode {
protected:
    using DualNode::GetNext;
    using DualNode::GetPrev;
public:
    virtual ExtendedNode *const GetNext() const { return static_cast<ExtendedNode *>(DualNode::GetNext()); }
    virtual ExtendedNode *const GetPrev() const { return static_cast<ExtendedNode *>(DualNode::GetPrev()); }
};

І в деяких випадках це дуже корисна штука, яка піднімає модифікатор доступу для вказаних полів і методів. Але в мене воно не дозволяло одночасно піднімати модифікатор з private до protected (або public) і при цьому перевизначати тіло методу.
Я думаю розробники просто недооцінили збоченість деяких програмістів (таких як я), ну і мабуть спростили собі життя за рахунок блокування перевизначення private-успадкованих методів.
Грець з ними, буду жити з protected-наслідуванням, воно принаймні компілюється.
Сподіваюсь я просто чогось не знаю або не розумію в розробці архітектури на C++, бо інакше мова С++ (Visual C++) - як мінімум недопрацьована.