Archived

This topic is now archived and is closed to further replies.

This topic is 5379 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

in a OOP way of thinking, i created an object which will serve as an object''s ID
  
class       BaseIdent
{
public:
      BaseIdent();
      BaseIdent(std::string);

      void          Ident(std::string  lIdent);
      std::string   Ident();
protected:
private:
      std::string       mIdent;
};
  
good,bad? a better way of doing it? functionality is more important than speed...

Share this post


Link to post
Share on other sites
What is it meant to do?

Is it a base class to be derived from? You should give it a virtual destructor.

The protected keyword doesn''t achieve anything.

Passing by const reference rather than by value is the normal way to do things.

If it''s an object that will be unique it may be a good idea to provide comparison and assignment operators.

Share this post


Link to post
Share on other sites
You might want to have a look at RTTI (Run time type identification) this is a C++ feature that allows you to find out what the datatype of an object is at run time and I think it includes a function called typeid().

Sorry I don’t know much more about it than that, but it maybe a better way to achieve what you want to do.

Share this post


Link to post
Share on other sites
getting information about objects at runtime is a capability of c++ but doesn''t mean it''s a good thing to use.

switching behaviour based on type can mean you''ve missed the point of polymorphism.

Share this post


Link to post
Share on other sites
RTTI allows you to see what class an object is an instance of. It won''t help you to differentiate between various instances of that class. In my game, I am using an ID class that looks like this:

ID.h

  
#ifndef CID_H
#define CID_H

#include <windows.h>

class CID
{
public:
CID();
virtual ~CID();
int GetID() const;

bool operator==(const CID& OtherEntity) const;
bool operator!=(const CID& OtherEntity) const;

private:
int m_nID;
static int m_nNextID;
};
#endif


ID.cpp

  
#include "ID.h"

int CID::m_nNextID = 0;

CID::CID()
{
m_nID = CID::m_nNextID++;
}

CID::~CID()
{
}

int CID::GetID() const
{
return m_nID;
}

bool CID::operator==(const CID& OtherEntity) const
{
return m_nID == OtherEntity.GetID();
}

bool CID::operator!=(const CID& OtherEntity) const
{
return m_nID != OtherEntity.GetID();
}


I use this CID class as a base class for any class that needs to instantiate objects that need to be uniquely identified. Every time an object is created, it automatically gets a unique integer ID #.

Also, unless you specifically need to, you shouldn''t store the object''s ID as a string. Comparing strings is much slower than comparing integers.

Good luck!

-Mike

Share this post


Link to post
Share on other sites
i think u guys are going in the wrong way

i just wanna create a base class which will serve as an id, on which objects can be sorted, etc...

dr6string: like said, strings provide more functionality, which i cannot achive with int''s


  
class BaseIdent
{
public:
BaseIdent();
BaseIdent(std::string);
virtual ~BaseIDent();
inline void Ident(const std::string lIdent);
inline std::string Ident();
protected:
private:
std::string mIdent;
};


also, should mIDent be protected?
should,can con''s and des be inlined?

Share this post


Link to post
Share on other sites
''should'' is a funny word.

Anyway, in the object oriented world, data should be encapsulated. So it should always be private. In C++ you can have it protected and public too but that doesn''t mean there is a case where you should ever do that.

Inlining will increase coupling between header files, increasing compile times when things change. You should only start to make functions inline towards the end of your project when you are tweaking, timing and testing to ensure it has the effect you want. Inlining can cause cache misses which can cause your program to decrease in performance. It causes code bloat etc. etc. What I''m saying is - leave it ''til later when you are able to justify it or rule it out.

Is that enough shoulds for you?

Actually I still don''t really understand what this is being used for. Will you have the comparison operators defined too?Will it be a member of every class or will they all derive from it? It seems a bit strange to me.

Share this post


Link to post
Share on other sites
other objects will derive from BaseIdent
like:

class Person: public class BaseIdent

now every Person has an ident...

and i can do:

Person A("A");
Person B("B");

if (A.Ident() > B.Ident())
do stuff

as for protected:
lets say class Person has a Log function, like

void Log()
{
a: my_file << Ident();
b: my_file << mIdent;
}

if protected, b is possible, but is it better than a?

i'll take ur advice on inlining


addon: b) choice sucks

[edited by - original vesoljc on March 25, 2003 4:27:35 PM]

Share this post


Link to post
Share on other sites