Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > How to create an alias - overlaying two class hierarchies

Reply
Thread Tools

How to create an alias - overlaying two class hierarchies

 
 
Matt
Guest
Posts: n/a
 
      10-06-2009

Please help me. I really don't know a solution to this.

I am trying to re-merge two versions of a library after a badly accepted
code split. FLTK 1 is stable and has very few bugs. It has been
developed in parallel with FLTK 2. FLTK 2 has (by far) a better API, but
has become unstable due to the lack of TLC.

My plan is to map the FLTK 2 API onto the FLTK 1 guts, creating FLTK 3
which is source code compatible to 1 *and* 2.


This is part of the class hierarchy:

class Fl_Widget
class Fl_Group : public Fl_Widget
class Fl_Window : public Fl_Group

and

class fltk::Widget
class fltk::Group : public fltk::Widget
class fltk::Window : public fltk::Group

Now I need a true alias that maps Fl_Widget to fltk::Widget, etc. .

(1) A typedef does not do because a forward declaration of Fl_Widget
would fail:

class Fl_Widget *somePointer;
#include <Widget.h>
typedef fltk::Widget Fl_Widget; // error

(2) The I tried stub classes, generating this hierarchy

class fltk::Widget
class Fl_Widget : public fltk::Widget
class fltk::Group : public fltk::Widget
class Fl_Group : public fltk::Group
class fltk::Window : public fltk::Group
class Fl_Window : public fltk::Window

This fails because Fl_Group is no longer derived from Fl_Widet

(3) This may work, but it *u*gly!

class fltk::Widget
class Fl_Widget : public fltk::Widget
class fltk::Group : public Fl_Widget
class Fl_Group : public fltk::Group
class fltk::Window : public Fl_Group
class Fl_Window : public fltk::Window

(4) Using #define is out of the question... .


Any help is greatly appreciated!


Matthias

 
Reply With Quote
 
 
 
 
Francesco S. Carta
Guest
Posts: n/a
 
      10-07-2009
On 6 Ott, 18:42, Matt <(E-Mail Removed)> wrote:
> Please help me. I really don't know a solution to this.
>
> I am trying to re-merge two versions of a library after a badly accepted
> code split. FLTK 1 is stable and has very few bugs. It has been
> developed in parallel with FLTK 2. FLTK 2 has (by far) a better API, but
> has become unstable due to the lack of TLC.
>
> My plan is to map the FLTK 2 API onto the FLTK 1 guts, creating FLTK 3
> which is source code compatible to 1 *and* 2.
>
> This is part of the class hierarchy:
>
> class Fl_Widget
> class Fl_Group : public Fl_Widget
> class Fl_Window : public Fl_Group
>
> and
>
> class fltk::Widget
> class fltk::Group : public fltk::Widget
> class fltk::Window : public fltk::Group
>
> Now I need a true alias that maps Fl_Widget to fltk::Widget, etc. .
>
> (1) A typedef does not do because a forward declaration of Fl_Widget
> would fail:
>
> class Fl_Widget *somePointer;
> #include <Widget.h>
> * *typedef fltk::Widget Fl_Widget; // error
>
> (2) The I tried stub classes, generating this hierarchy
>
> class fltk::Widget
> class Fl_Widget : public fltk::Widget
> class fltk::Group : public fltk::Widget
> class Fl_Group : public fltk::Group
> class fltk::Window : public fltk::Group
> class Fl_Window : public fltk::Window
>
> This fails because Fl_Group is no longer derived from Fl_Widet
>
> (3) This may work, but it *u*gly!
>
> class fltk::Widget
> class Fl_Widget : public fltk::Widget
> class fltk::Group : public Fl_Widget
> class Fl_Group : public fltk::Group
> class fltk::Window : public Fl_Group
> class Fl_Window : public fltk::Window
>
> (4) Using #define is out of the question... .
>
> Any help is greatly appreciated!


Try posting more details - the interfaces of those classes, in
particular.

Also, I'm not so sure about what TLC stands for, here, top-level
classes perhaps?

A hierarchy could have nothing wrong in itself but its application can
be partially or totally wrong, depending on the cases.

Also, why did you write "this may work" for (3)? Didn't you test it?
Depending on the cases, that could be the only way to avoid rewriting
the interface.

--
Francesco S. Carta, http://fscode.altervista.org
First time here? Read the 'Welcome' and the 'FAQ'
Welcome: http://www.slack.net/~shiva/welcome.txt
C++ FAQ: http://www.parashift.com/c++-faq-lite
 
Reply With Quote
 
 
 
 
Michael Doubez
Guest
Posts: n/a
 
      10-07-2009
On 7 oct, 12:07, "Francesco S. Carta" <(E-Mail Removed)> wrote:
> On 6 Ott, 18:42, Matt <(E-Mail Removed)> wrote:
>
>
>
> > Please help me. I really don't know a solution to this.

>
> > I am trying to re-merge two versions of a library after a badly accepted
> > code split. FLTK 1 is stable and has very few bugs. It has been
> > developed in parallel with FLTK 2. FLTK 2 has (by far) a better API, but
> > has become unstable due to the lack of TLC.

>
> > My plan is to map the FLTK 2 API onto the FLTK 1 guts, creating FLTK 3
> > which is source code compatible to 1 *and* 2.

>
> > This is part of the class hierarchy:

>
> > class Fl_Widget
> > class Fl_Group : public Fl_Widget
> > class Fl_Window : public Fl_Group

>
> > and

>
> > class fltk::Widget
> > class fltk::Group : public fltk::Widget
> > class fltk::Window : public fltk::Group

>
> > Now I need a true alias that maps Fl_Widget to fltk::Widget, etc. .

>
> > (1) A typedef does not do because a forward declaration of Fl_Widget
> > would fail:

>
> > class Fl_Widget *somePointer;
> > #include <Widget.h>
> > * *typedef fltk::Widget Fl_Widget; // error

>
> > (2) The I tried stub classes, generating this hierarchy

>
> > class fltk::Widget
> > class Fl_Widget : public fltk::Widget
> > class fltk::Group : public fltk::Widget
> > class Fl_Group : public fltk::Group
> > class fltk::Window : public fltk::Group
> > class Fl_Window : public fltk::Window

>
> > This fails because Fl_Group is no longer derived from Fl_Widet

>
> > (3) This may work, but it *u*gly!

>
> > class fltk::Widget
> > class Fl_Widget : public fltk::Widget
> > class fltk::Group : public Fl_Widget
> > class Fl_Group : public fltk::Group
> > class fltk::Window : public Fl_Group
> > class Fl_Window : public fltk::Window

>
> > (4) Using #define is out of the question... .

>
> > Any help is greatly appreciated!

>
> Try posting more details - the interfaces of those classes, in
> particular.
>
> Also, I'm not so sure about what TLC stands for, here, top-level
> classes perhaps?


I think he means TCL (Tool Command Language) like tcl/tk.


> A hierarchy could have nothing wrong in itself but its application can
> be partially or totally wrong, depending on the cases.


A hierarchy is a problem when you inherit an implementation, and
looking rapidely at fltk, it is the case here.

To the OP, your solution (2) may work if you virtually inherit:
class fltk::Widget
class Fl_Widget : public virtual fltk::Widget

class fltk::Group : public virtual fltk::Widget
class Fl_Group : public virual fltk::Group, public virtual Fl_Widget

class fltk::Window : public virtual fltk::Group
class Fl_Window : public fltk::Window, public virtual Fl_Group


--
Michael
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      10-07-2009
On 7 Ott, 15:48, Michael Doubez <(E-Mail Removed)> wrote:
> On 7 oct, 12:07, "Francesco S. Carta" <(E-Mail Removed)> wrote:
>
>
>
> > On 6 Ott, 18:42, Matt <(E-Mail Removed)> wrote:

>
> > > Please help me. I really don't know a solution to this.

>
> > > I am trying to re-merge two versions of a library after a badly accepted
> > > code split. FLTK 1 is stable and has very few bugs. It has been
> > > developed in parallel with FLTK 2. FLTK 2 has (by far) a better API, but
> > > has become unstable due to the lack of TLC.

>
> > > My plan is to map the FLTK 2 API onto the FLTK 1 guts, creating FLTK 3
> > > which is source code compatible to 1 *and* 2.

>
> > > This is part of the class hierarchy:

>
> > > class Fl_Widget
> > > class Fl_Group : public Fl_Widget
> > > class Fl_Window : public Fl_Group

>
> > > and

>
> > > class fltk::Widget
> > > class fltk::Group : public fltk::Widget
> > > class fltk::Window : public fltk::Group

>
> > > Now I need a true alias that maps Fl_Widget to fltk::Widget, etc. .

>
> > > (1) A typedef does not do because a forward declaration of Fl_Widget
> > > would fail:

>
> > > class Fl_Widget *somePointer;
> > > #include <Widget.h>
> > > * *typedef fltk::Widget Fl_Widget; // error

>
> > > (2) The I tried stub classes, generating this hierarchy

>
> > > class fltk::Widget
> > > class Fl_Widget : public fltk::Widget
> > > class fltk::Group : public fltk::Widget
> > > class Fl_Group : public fltk::Group
> > > class fltk::Window : public fltk::Group
> > > class Fl_Window : public fltk::Window

>
> > > This fails because Fl_Group is no longer derived from Fl_Widet

>
> > > (3) This may work, but it *u*gly!

>
> > > class fltk::Widget
> > > class Fl_Widget : public fltk::Widget
> > > class fltk::Group : public Fl_Widget
> > > class Fl_Group : public fltk::Group
> > > class fltk::Window : public Fl_Group
> > > class Fl_Window : public fltk::Window

>
> > > (4) Using #define is out of the question... .

>
> > > Any help is greatly appreciated!

>
> > Try posting more details - the interfaces of those classes, in
> > particular.

>
> > Also, I'm not so sure about what TLC stands for, here, top-level
> > classes perhaps?

>
> I think he means TCL (Tool Command Language) like tcl/tk.


Looking up TLC led to several acronym expansions, but having failed to
find one that fit, I made one up

> > A hierarchy could have nothing wrong in itself but its application can
> > be partially or totally wrong, depending on the cases.

>
> A hierarchy is a problem when you inherit an implementation,


Amen.

> looking rapidely at fltk, it is the case here.


Oops, I thought the fltk thingie was something peculiar to the OP's
project, but since you were able to find those details somewhere else,
that had to be some third-party library.

I didn't even think about looking it up, first time I hear about,
thanks for pointing it out.

Damn, seems I'm a bit behind in the "IT acculturated" trail

--
Francesco S. Carta, http://fscode.altervista.org
 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      10-08-2009
Michael Doubez wrote:
>> Also, I'm not so sure about what TLC stands for, here, top-level
>> classes perhaps?

>
> I think he means TCL (Tool Command Language) like tcl/tk.


Oh, sorry, TLC stands for "tender love and care". I meant to say that we
did not take care of the fltk2 branch as we should have.

>> A hierarchy could have nothing wrong in itself but its application can
>> be partially or totally wrong, depending on the cases.

>
> A hierarchy is a problem when you inherit an implementation, and
> looking rapidely at fltk, it is the case here.


FLTK needed to be written to replace the Forms Library, a decades old
Graphical User Interface library. It needed to be source code
compatible. The class structure is - um - bearable, but really easy to
understand, which makes FLTK a great beginner GUI library. It has been
taught until recently at several universities.

FLTK2 was the attempt to clean up the major flaws, but never took of,
because user with existing code would not jump from V1 to V2, afraid of
the changes required in their source code.

Now we ended up with two libraries with 90% feature overlap, one stable
with an ancient API, the other instable, but as many users and a better API.

My goal is to move the stable version, FLTK 1, up and call it FLTK 3,
but implementing both APIs, so we don't lose any more users. Then the
additional features of FLTK 2 will be ported to FLTK 3. I am not sure if
this a sound strategy, but I would like to give it a try and see what
the acceptance will be.

The problem is the aliasing of the class hierarchy which must not be
even messier than what we have

> To the OP, your solution (2) may work if you virtually inherit:
> class fltk::Widget
> class Fl_Widget : public virtual fltk::Widget
>
> class fltk::Group : public virtual fltk::Widget
> class Fl_Group : public virual fltk::Group, public virtual Fl_Widget
>
> class fltk::Window : public virtual fltk::Group
> class Fl_Window : public fltk::Window, public virtual Fl_Group


Thank you, I will try that out. Does that mean that the virtually
inherited classes must be pure virtual, too?

Francesco: (3) I see no reason why (3) wouldn't work, but I havn't
tested it yet. It feels a bit brute force to me and I was hoping for a
more elegant version.

Thanks for the hints,

Matthias
 
Reply With Quote
 
Michael Doubez
Guest
Posts: n/a
 
      10-08-2009
On 8 oct, 12:45, Matt <(E-Mail Removed)> wrote:
> Michael Doubez wrote:
> >> Also, I'm not so sure about what TLC stands for, here, top-level
> >> classes perhaps?

>
> > I think he means TCL (Tool Command Language) like tcl/tk.

>
> Oh, sorry, TLC stands for "tender love and care". I meant to say that we
> did not take care of the fltk2 branch as we should have.


Not caring enough to spell it full then

[snip]
>
> > To the OP, your solution (2) may work if you virtually inherit:
> > class fltk::Widget
> > class Fl_Widget : public virtual fltk::Widget

>
> > class fltk::Group : public virtual fltk::Widget
> > class Fl_Group : public virual fltk::Group, public virtual Fl_Widget

>
> > class fltk::Window : public virtual fltk::Group
> > class Fl_Window : public fltk::Window, public virtual Fl_Group

>
> Thank you, I will try that out. Does that mean that the virtually
> inherited classes must be pure virtual, too?


Not necessarily. That depends on own your class map to one another.

It solves the diamond shape inheritance. That way you will have the
following hierarchy:
Widget
| \
| FL_Widget
| |
Group |
| \ |
| FL_Group
| |
Window |
\ |
FL_Window


Group and FL_Group will share the same inherited Widget instance.

> Francesco: (3) I see no reason why (3) wouldn't work, but I havn't
> tested it yet. It feels a bit brute force to me and I was hoping for a
> more elegant version.


If you don't need to bridge the two hierarchy (i.e. a FL_Widget* must
not be a fltk::Widget*), you could just use composition and keep the
types orthogonals:

// FL_Widget uses internally a fltk::Widget.
class FL_Widget
{
fltk::Widget* widget;

public:
FL_Widget():widget(new fltk::Widget())
{}

// interface uses widget

protected:
FL_Widget(fltk::Widget* w):widget(w)
{}
void setWidget(fltk::Widget* w)
{
widget=w;
}
};

And in case of inheritance, you intialize according to decorated
object:
class FL_Group: public FL_Widget
{
fltk::Group* group;

public:
FL_Group():FL_Widget(NULL)
,group(new fltk::Group())
{ setWidget(group); }

// interface uses group

protected:
FL_Group(fltk::Group* g):FL_Widget(g),group(g)
{}
void setGroup(fltk::Group* g)
{
group=g;
setWidget(group);
}
};

// ...

You would also have to redefine copy constructor and operator to make
your classes canonical; beware of destructor which must set its
hierarchy to NULL to avoid multiple deletion.

--
Michael
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      10-08-2009
Matt <(E-Mail Removed)> wrote:
> Francesco: (3) I see no reason why (3) wouldn't work, but I havn't
> tested it yet. It feels a bit brute force to me and I was hoping for a
> more elegant version.


I hope that Michael's suggestion will help you find the optimal
solution for your issue.

I just realized that you're one of the library's implementers, so yes,
that's something peculiar to your project and no, from your POV that's
not a third-party library

I'm interested in checking it out, but I'm having hard time getting it
- my fault, I have a weird proxyed connection. I'm going to send you
an e-mail to the addresses I've found on your personal website, you'll
eventually hand me some non-ftp link.

Good luck for your projects,
cheers,
Francesco
--
Francesco S. Carta, http://fscode.altervista.org
 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      10-08-2009
Francesco S. Carta wrote:
> Matt <(E-Mail Removed)> wrote:
> I just realized that you're one of the library's implementers, so yes,
> that's something peculiar to your project and no, from your POV that's
> not a third-party library


Well, with a few hundred users, it feels like a third party library in
that I can't change the API (much) or even the ABI between revisions. At
least I have full access to the internals

> I'm interested in checking it out, but I'm having hard time getting it
> - my fault, I have a weird proxyed connection. I'm going to send you
> an e-mail to the addresses I've found on your personal website, you'll
> eventually hand me some non-ftp link.


No problem. The http download is here:

http://ftp.easysw.com/pub/fltk/

> Good luck for your projects,


Thanks a lot for your interest. After 12 years of being one of the core
developers, the brain plays funny tricks with code and structures. I
kind of feel like I personally know every line of code

Matthias
 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      10-08-2009
Michael Doubez wrote:

> It solves the diamond shape inheritance. That way you will have the
> following hierarchy:
> Widget
> | \
> | FL_Widget
> | |
> Group |
> | \ |
> | FL_Group
> | |
> Window |
> \ |
> FL_Window
>
>
> Group and FL_Group will share the same inherited Widget instance.


Phew, yes. I read myself into the diamond problem a little (and suddenly
remembered why I always avoided it . I gave it a quick try, but
haven't wrapped my head around it yet. I will try with a smaller project
first.

>> Francesco: (3) I see no reason why (3) wouldn't work, but I havn't
>> tested it yet. It feels a bit brute force to me and I was hoping for a
>> more elegant version.

>
> If you don't need to bridge the two hierarchy (i.e. a FL_Widget* must
> not be a fltk::Widget*)


Sorry, no, I'll have to provide that.

I did another quick try with - hold your breath - using a simple
"define". While this throws up different (solvable) issues, I was
successful in compiling an FLTK 1 and almost an FLTK 2 program without
changing a line of code. Quite unsatisfying though.

> You would also have to redefine copy constructor and operator to make
> your classes canonical; beware of destructor which must set its
> hierarchy to NULL to avoid multiple deletion.


Thanks for all the help!

Matthias
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      10-09-2009
On 8 Ott, 20:50, Matt <(E-Mail Removed)> wrote:
> Francesco S. Carta wrote:
> > Matt <(E-Mail Removed)> wrote:
> > I just realized that you're one of the library's implementers, so yes,
> > that's something peculiar to your project and no, from your POV that's
> > not a third-party library

>
> Well, with a few hundred users, it feels like a third party library in
> that I can't change the API (much) or even the ABI between revisions. At
> least I have full access to the internals


It's better to have such limitations, due to the consistency of the
user-base.
At least, this will push all the team towards injecting some more TLC
into the next revisions - sorry, I couldn't resist making this
malicious statement

> > I'm interested in checking it out, but I'm having hard time getting it
> > - my fault, I have a weird proxyed connection. I'm going to send you
> > an e-mail to the addresses I've found on your personal website, you'll
> > eventually hand me some non-ftp link.

>
> No problem. The http download is here:
>
> http://ftp.easysw.com/pub/fltk/


Thanks, I was finally able to get it from the above link.

> > Good luck for your projects,

>
> Thanks a lot for your interest. After 12 years of being one of the core
> developers, the brain plays funny tricks with code and structures. I
> kind of feel like I personally know every line of code


You're welcome, I'm about to compile and try it out, I'll get in touch
with your community.

Cheers,
Francesco
--
Francesco S. Carta, http://fscode.altervista.org
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
reference/alias in perl vs reference/alias in C++ grocery_stocker C++ 9 05-24-2008 04:32 AM
XP X64 Pro, IE7, Delphi 2007, IntraWeb, MS Access, ODBC Alias problem: Insufficient memory for this operation. Alias: SomeDatabase. Skybuck Flying Windows 64bit 13 01-09-2008 07:34 PM
Parametric covariance in class hierarchies Matthias Kaeppler Java 6 01-23-2006 09:01 AM
2 class hierarchies design question S. S. Tsay Java 1 06-25-2004 01:22 PM



Advertisments