class BaseIdent
{
public:
BaseIdent();
BaseIdent(std::string);
void Ident(std::string lIdent);
std::string Ident();
protected:
private:
std::string mIdent;
};
object id
Author
in a OOP way of thinking, i created an object which will serve as an object''s ID
good,bad?
a better way of doing it?
functionality is more important than speed...
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.
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.
Author
it is a base class and will be derived from, virtual destructor is/will be there.
void Ident(const std::string &lIdent); this better?
protected is a "leftover" from a simple class template i use for typing
void Ident(const std::string &lIdent); this better?
protected is a "leftover" from a simple class template i use for typing
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.
Sorry I don’t know much more about it than that, but it maybe a better way to achieve what you want to do.
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.
switching behaviour based on type can mean you''ve missed the point of polymorphism.
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
ID.cpp
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
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
Author
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
also, should mIDent be protected?
should,can con''s and des be inlined?
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?
''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.
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.
Author
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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
