Skip to main content
GameDev.net gamedev.net
🔒 Locked

Inheritance problem.. again..

Started by HellRiZZer Oct 12, 2003 at 10:40 PM 6 replies 350+ views
Original Post
HellRiZZer
HellRiZZer
Hi guys, I still having a trouble with the following inheritance/interface code: ResourceEntry.h
class IResourceData
{
	public:

		IResourceData() {};
		~IResourceData() {};
};

class IResourceEntry
{
public:
	virtual bool Create(IResourceEntry *data); // Can be overriden for simple resource types

	virtual void Destroy() = 0;
	
	virtual int LoadResource(char *filename, FILE *file) = 0;
	virtual int SaveResource(char *filename, FILE *file) = 0;

	IResourceEntry *GetData()
	{ return m_pData; };

	eResourceEntryType GetResourceType()
	{ return m_eResourceType; };

public:
	IResourceEntry();
	virtual ~IResourceEntry();

protected:
	IResourceEntry *m_pData;
	eResourceEntryType m_eResourceType;
};
TextureResource
class CTextureResourceData : public IResourceData
{
public:
	FIBITMAP		*m_hFI;	// A user can actually operate on this entry by using FreeImage library functions (see freeimage.h)

	FREE_IMAGE_FORMAT m_TexFmt;	// DO NOT CHANGE THIS!

	
	CTextureResourceData()
	{
		m_hFI = NULL;
		m_TexFmt = FIF_UNKNOWN;
	};

	~CTextureResourceData() {};
};

class CTextureResourceEntry : public IResourceEntry
{
public:

	bool Create(CTextureResourceData *data)
	{ return Create(data); };

	void Destroy();

	virtual void GenTex(int params, ...) {};

	virtual int LoadResource(char *filename, FILE *file);
	virtual int SaveResource(char *filename, FILE *file);

	void CreateAlphaChannel(RGBA color);

public:
	CTextureResourceEntry()
	{
		Create(new CTextureResourceData);
		m_eResourceType = RESOURCETYPE_TEXTURE; 
	};

	virtual ~CTextureResourceEntry();

private:
	string			m_strTexFilename;			// File name

};

The problem is, when I create a CTextureResourceEntry (thru new operator to a pointer), it calls IResourceEntry constructor - and that''s I don''t need to happen. How can I go around it so it calls ONLY ITS OWN constructor? E.g CTextureResourceEntry will be calling ONLY its constructor, and other classes derived from CTextureResourceEntry ( say, CMaterialResourceEntry) will also be calling only thier constructor and not the derived ones? Thanks. " Do we need us? "

Ionware Productions - Games and Game Tools Development

Sneftel
Sneftel
There''s no way around that. Part of a CTextureResourceEntry IS a IResourceEntry, so that part of it has to be constructed. Why don''t you want this happening?


How appropriate. You fight like a cow.
HellRiZZer
HellRiZZer
I don''t want this to happen simply because if I create another class derived from CTextureResourceEntry (CMaterialResourceEntry) and do same thing in constructor as in CTextureResourceEntry ( Create(new CMaterialResourceData)), it will give me a memory leak, and I want to avoid it.

Thanks for a fast reply.

" Do we need us? "


Ionware Productions - Games and Game Tools Development

dmikesell
dmikesell
eResourceEntryType GetResourceType()	{ return m_eResourceType; };


What is this? Some kind of run-time type identification? That's a sure sign that your inheritance tree is broken.

Clients should be able to use a pointer/reference to IResourceData generically without having to know the type of the concrete class. If they can't, refactor your code.

Do a Google search on the "Liskov Substitution Principle" and/or pick up a copy of /C++ FAQS/ and read the chapter on proper inheritance.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

[edited by - dmikesell on October 13, 2003 8:36:49 AM]

[edited by - dmikesell on October 13, 2003 12:42:28 PM]
dmikesell
dmikesell
quote:
It''s a UID for each resource derived from basic IResourceEntry - if I derive CTextureResourceEntry from IResourceEntry, then in constructor I assign m_eResourceType to RESTYPE_TEXTURE.


So do you have code that looks like this:


void processResource(IResourceEntry & res)
{
if (res.eResourceEntryType() == RESTYPE_TEXTURE) {
// process texture

} else if (res.eResourceEntryType() == SOMEOTHERTYPE) {
// process some other resource

} ...
}


If so, why bother building an inheritance tree if all of the derived types break the base class interface?

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.