I guess the answer is Yes and No.
The question is when you define
struct D:B
Is B guaranteed to be aligned at offset 0 within D?
If the answer is yes, then probably. If the answer is no, then no.
Tough I assume this would also have an implication in code generation as certain methods marked as final can sometimes be optimized by directly replacing the address of the final method instead of looking at the vtable. And since you can't always see if a method is re-declared final or not it will have some funny consequences.

I don't think I know enough to be able to say if this is problematic or not. But I can see it having some hurdles to overcome.


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Phil Endecott via Std-Proposals
Sent: Monday, December 30, 2024 2:44 PM
To: std-proposals_at_lists.isocpp.org
Cc: Phil Endecott <std_proposals_list_at_chezphil.org>
Subject: [std-proposals] Partial forward class declarations

Dear Experts,

Consider:

struct A {
  virtual ~A() = default;
  ....
};

struct B: A {
  ....
};


class C {
  struct D: B {
    ....
  };

public:
  D* d; // Or unique_ptr<D> etc.
  ....
};


Let's say that C is declared in C.hpp. I could forward-declare D in that header:

class C {
  struct D;
public:
  D* d;
};


Question: has the idea of a "partial forward declaration" ever been considered, where D is declared as a struct that inherits from B, but with the body omitted? E.g.:

class C {
  struct D: B;
public:
  D* d;
};


The aim is to make it possible for a user of C to use the methods defined in A and B, while keeping the details of D hidden.

Is this implementable? I could imagine that there could be issues with multiple inheritance.

Of course an alternative is:

class C {
  struct D;
public:
  B* d;
};

The disadvantage of this is that within the implementation of C, where I know that d is actually a D*, I would constantly need to cast it.

This idea of partial forward declarations has occurred to me before with slightly different motivations.

Thoughts anyone?

Phil.


--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals