• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 314
  • Last Modified:

C++ Derived Classes

Hello,

I am currently building many containers to hold various types of information that is being extracted from logs. I have vectors and multisets to store the objects of certain classes that are being created from the parsing of the logs. For example, I have an ACTOR class that has attributes of name and address. However, I also want a CONVERSATION class to be an object of each ACTOR class, which i want to store in containers as they are created.
So I effectively want an object of an object - both of which will be stored in a container.

I am doing this because i want to be able to count the number of conversations per actor depending on certain attributes of the conversation object.

so for example i would create the new actor object within a mulitset using something like
actor_set.insert(actor(name, address, age)).

When i continue to parse the file and a conversation corresponding to the  actor.name is discovered, I want to insert a conversation object within the actor object and keep adding to it as more conversations are found.

If anyone understands what I am trying to do - but could offer a better alternative - I would appreciate the advice. I cant use arrays as I dont want to predefine the size.

Get it?? Sorry for the ambiguity ....:(

simondo
0
simondopickup
Asked:
simondopickup
  • 8
  • 5
  • 2
  • +2
3 Solutions
 
evilrixSenior Software Engineer (Avast)Commented:
I understand what you're doing but not what the problem is. It seems like a reasonable object model to me.
0
 
Infinity08Commented:
Just a little thought : wouldn't a conversation involve 2 or more actors ?
0
 
wizzardofozCommented:
I would suggest that conversations be held in a separate container but an array of GUID's referring to the conversations be in each actor class. That would take care of the multiple actor per conversation problem.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
evilrixSenior Software Engineer (Avast)Commented:
>> but an array of GUID's referring to the conversations
How about just iterators into an STL cointainer? That's the more natural way to handle cross-container references in C++.
0
 
maartennieberCommented:
Storing iterators could have the danger that an iterator may become invalid at some point.
Another way would be to store the conversations in a set of smart pointers, using for example the  shared_ptr class from the Boost C++ libraries:

typedef boost::shared_ptr<Conversation> ConversationPtr;
typedef std::set<ConversationPtr> ConversationSet;

ConversationSet conversations;
ConversationPtr newConversation = ConversationPtr(new Conversation());
conversations.insert(newConversation);

As long as a ConversationPtr is stored in some ConversationSet, it will be kept alive.
Using std::set will ensure that an Actor will not store the same Conversation twice.
0
 
evilrixSenior Software Engineer (Avast)Commented:
>> Storing iterators could have the danger that an iterator may become invalid at some point.
only if you choose a container type that can invalidate iterators when a mutating member function is called (such as a vector). The only way ths would be a problem on a node based container is if the element the iterator points to is removed and this is semantically no diffent to a hangng pointer (even one in a smart pointer). The solution is to choose the correct type of container (any node based container), not introduce unnecessary layers of complexity.

>> Using std::set will ensure that an Actor will not store the same Conversation twice.
Storing (potentially) large strings in a set is inefficient. Although the complexity for inserting and traversing a set is O(log N) the time it takes is proportional to the time taken fo the operator <() to facilitate this. In the case of a conversation, this has a potential complexity of O(N) where N is the average length of each conversation string. I'd suggest using a map, with the key being digest of the conversation string (MD5 or SHA1 for example) and the value being the conversation string. This will give you ease of lookng up a conversation (calculating a hash still has a complexiy of O(N) but it only needs to be done once) combined with the uniqueness qualities provided by a set but with a more efficient time complexity for performing the look-up. The source code for both MD5 and SHA1 can be found with the RFCs for these digests or can be implemented via the Windows Crypto API (CAPI).

http://msdn.microsoft.com/en-us/library/aa380255(VS.85).aspx
0
 
simondopickupAuthor Commented:
Evilrx contributed the most..in the end ;) - it has been enough to get me going.

Can someone look at my other open question!!!!!!!!!!!!!1 argghhhh

http://www.experts-exchange.com/Programming/Languages/CPP/Q_24391623.html
0
 
maartennieberCommented:
>> Storing (potentially) large strings in a set is inefficient.
The set is storing the smart pointers, not the conversations themselves.
0
 
evilrixSenior Software Engineer (Avast)Commented:
>> The set is storing the smart pointers, not the conversations themselves.
Then how are you gong to do a lexical search?
0
 
maartennieberCommented:
I would iterate over the elements in the set and search within each element.
In any case it is best not to expose the datatype used for storing the conversations (be it a set, a map or something else) to the clients of the class since it is an implementation detail.
If searching in a set of smart pointers would turn out to be too slow (after running the profiler), it can be replaced with a more complex and efficient approach without breaking any code.

0
 
evilrixSenior Software Engineer (Avast)Commented:
>> I would iterate over the elements in the set and search within each element.
But then you are ignoring one of the benefits of using a set, locating data in O(log N) time. Your solution will require O(N) time nd gains nothing for this cost.

>> In any case it is best not to expose the datatype used for storing the conversations
And yet you are doing exactly this by forcing the user of the set to know they have to iterate it because of the data type being used.

>> it can be replaced with a more complex and efficient approach without breaking any code.
I can be replced with what I suggested, which is not complex and yet is efficient.

0
 
simondopickupAuthor Commented:
I love it. Great value for points.

 Evilrx - why dont you have a Windows machine :S can you at least explain the 3 questions i asked in the post just from c++ knowledge?!!
0
 
evilrixSenior Software Engineer (Avast)Commented:
>> Evilrx - why dont you have a Windows machine
I don't need one that's why :)

>> can you at least explain the 3 questions i asked in the post just from c++ knowledge?!!
I'll review and answer in the other thread
0
 
maartennieberCommented:
>> Your solution will require O(N) time nd gains nothing for this cost.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Donald Knuth)

>> And yet you are doing exactly this...
I think you misunderstood. I refered to the client of the Actor class (i.e. another class using the Actor class). This client need not be aware of the storage type used internally by Actor.

>> I can be replced with what I suggested, which is not complex and yet is efficient.
You say it is not complex, which suggests that it is not simple either, right? (Keep It Short and Simple)
0
 
evilrixSenior Software Engineer (Avast)Commented:
>> "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Donald Knuth)
Yes I too know this incorrectly attributed quote but there is a difference between premature optimizaion and good up-front design. In this case we are NOT talking about small efficiencies we are talking about a good and robust design that meets all the reuirements in an time efficient manner, without the need to add extra layers of complexity.

>> Keep It Short and Simple
It is simple!

I'm done with this, the discussion is now moot.

0
 
evilrixSenior Software Engineer (Avast)Commented:
Sorry, just one fnal point from me, the following link discusses Hoare's Dictim (the original quote comes from Sir Charles Antony Richard Hoare, who invnted the Quick Sort). It goes on to explain why this quote is often misunderstood and, as such, why inexperienced programmers often go on to develop non-scalable solutions. This is, bascally, what I was eluding to above. Premaure optimization is often confused with good design.

http://www.cookcomputing.com/blog/archives/000084.html

Now I really am done with this :)
0
 
maartennieberCommented:
I fully agree with this post, but does this this warning about ignoring scalability apply here?
Choosing how to store conversations in the Actor class appears to be an implementation detail of the Actor class, not a system level decision.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 8
  • 5
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now