Sign in to follow this  

Returning pointers by giving a name

This topic is 3839 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

class entity { public: char [30]entityid; }; class trigger { public: char [30]triggerid; entity* returnentity(char [30]entityid); }; Can anyone give me ideas for the definition of the returnentity function so that it can return a pointer to a member of the entity class just by giving the members' name (entityid)? This is a little bit of a hard puzzle for me for some reason although I have the bad feeling it shouldn't be...

Share this post


Link to post
Share on other sites
First, consider using std::string instead of char[30].

Second, you might want to make your question more understandable. Check your example function names, in particular.

Third, there is no simple way of doing this in C++. Approaches you might consider are:
  • Using member pointers instead of strings as identifiers.
  • Using a static std::map of member pointers.
  • Using a single std::map member instead of several members.

Share this post


Link to post
Share on other sites
Quote:
Original post by JMaxwell
Can anyone give me ideas for the definition of the returnentity
function so that it can return a pointer to a member of the entity
class just by giving the members' name (entityid)?
I presume you mean "return a pointer to an instance of the entity class", not a member.
So where are all the instances held? Please show the array or container declaration.

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
First, consider using std::string instead of char[30].


I'd suggest finding a string hashing function and using 32-bit numerical values as identifiers instead.

The downside of this is that it makes error reporting a little annoying, as you're getting back hashed values instead of strings. But it makes searches and comparisons on the identifiers much faster, and is less error-prone.

Finding a good hashing function is the trick, though. I'm obviously not going to share the one we use at work, but a hashed ID system is frighteningly easy to work with if you have the right tools. (Macro in your editor to turn strings into IDs, lookup tool that indexes the strings in your data and code and can reverse the IDs, etc).

As for returnentity... you can implement it as a search in a variety of ways, depending on how you've stored the entities. The basic slow linear search will be fine if you've got a small number of entities per trigger. Psuedocode:

for entity in trigger
(
if entity.id == desired_id then return entity
)

where if you're going to use char*'s, you'd want the "==" to be a strcmp.

Share this post


Link to post
Share on other sites


class entity {};

typedef entity * EntityPtr;

...

class Lookup {
public:
Lookup( void ) {}

~Lookup( void )
{
// cleanup if needed by destroying the objects in m_entities
}

EntityPtr get_entity( const std::string &name )
{
EntityMap::iterator i = m_entities.find( name );
if ( i == entities.end() ) {
// invalid name
return NULL;
} else {
return i->second;
}
}

// returns true if entity was added, false if entity with this name
// already exists
bool add( const std::string &name, EntityPtr entity )
{
bool name_available = (get_entity( name ) != NULL);
if ( name_available) {
m_entities.insert( std::make_pair( name, entity ) );
}
return name_available;
}
private:
typedef std::map< std::string, EntityPtr > EntityMap;
EntityMap m_entities;
};

...

Lookup entity_lookup;
entity_lookup.add( "Foo", new entity() );

entityPtr foo = entity_lookup.get_entity( "Foo" );
entityPtr bar = entity_lookup.get_entity( "Bar" );
// foo is valid, bar is NULL




Lots of problems start here.

First is the pointer ownership. Who deletes the objects, the map, or the creator?

Best answer to that would be obviously using some form of smart pointers, or simply deciding that either map or the caller is responsible for deletion. With smart pointers there's also the problem of NULL value, which may be represented differently.

Second problem is the types. This is perfect example for templates which would allow addition of arbitrary type. The other would be inheritance, or simply requiring that all objects that are available for lookup extend entity.

Share this post


Link to post
Share on other sites

This topic is 3839 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this