Stack Abstract Data Type Question

Please support our C++ advertiser: Intel Parallel Studio Home
Reply

Join Date: Nov 2005
Posts: 27
Reputation: jack223 is an unknown quantity at this point 
Solved Threads: 0
jack223 jack223 is offline Offline
Light Poster

Stack Abstract Data Type Question

 
0
  #1
Sep 25th, 2007
Sorry~~, I don't know where to post this quetion.

Can someboy help me with this question, plz....

Suppose someone designed a stack abstract data type in which the top function returned an access path (or pointer), rather than returning a copy of the top element. This is not true data abstraction. Why?
Reply With Quote Quick reply to this message  
Join Date: Sep 2004
Posts: 7,856
Reputation: Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute Narue has a reputation beyond repute 
Solved Threads: 755
Team Colleague
Narue's Avatar
Narue Narue is offline Offline
Senior Bitch

Re: Stack Abstract Data Type Question

 
0
  #2
Sep 25th, 2007
>This is not true data abstraction.
Sure it is. The abstraction is the stack and its implementation, not the contents of the stack. Returning a copy of the top of the stack instead of a pointer to it makes no difference in how the stack works. Presumably the question is assuming that a malicious coder can break umpteen language rules to get a hold of other items if given a pointer to one item, but that's equally likely with nothing more than a stack object regardless of how much abstraction you put into it.
New members chased away this month: 4
Reply With Quote Quick reply to this message  
Join Date: Dec 2005
Posts: 5,850
Reputation: Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute 
Solved Threads: 751
Team Colleague
Salem's Avatar
Salem Salem is offline Offline
Void main'ers are DOOMed

Re: Stack Abstract Data Type Question

 
0
  #3
Sep 25th, 2007
It's certainly poor encapsulation.

Giving someone a pointer to the innards of your class exposes you to all sorts of problems. What if they try to write to your class data via the pointer? What if they increment the pointer, where does it point to then?
Applying all sorts of const to the result can only go so far.

Yes, std::string has the c_str() method which returns a pointer to something on the inside, but that's more a "necessary evil" rather than an example of good design IMO.
Reply With Quote Quick reply to this message  
Join Date: Dec 2006
Posts: 1,089
Reputation: vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all vijayan121 is a name known to all 
Solved Threads: 164
vijayan121 vijayan121 is offline Offline
Veteran Poster

Re: Stack Abstract Data Type Question

 
0
  #4
Sep 25th, 2007
very often, encapsulation/insulation and efficiency pull in opposite directions. and c++ programmers have to do a fine balancing act between the two and decide what is most appropriate in a particular case. for example,
  1. struct book // fully insulated, least efficient
  2. {
  3. book( const atring& t, const list<string>& a, const string& n ) ;
  4. book( const book& ) ;
  5. book& operator=( const book& ) ;
  6. ~book() ;
  7. string title() const ;
  8. list<string> authors() const ;
  9. string isbn() const ;
  10. // ...
  11. private:
  12. struct implementation ;
  13. implementation* opaque_pointer ;
  14. };
  1. struct book // encapsulated, partially insulated
  2. // more efficient
  3. {
  4. book( const atring& t, const list<string>& a, const string& n ) ;
  5. book( const book& ) ;
  6. book& operator=( const book& ) ;
  7. ~book() ;
  8. string title() const ;
  9. list<string> authors() const ;
  10. string isbn() const ;
  11. // ...
  12. private:
  13. string _title ;
  14. list<string> _authors ;
  15. string _isbn ;
  16. // ...
  17. };
  1. struct book // encapsulated, not insulated
  2. // even more efficient (inlining)
  3. {
  4. book( const atring& t, const list<string>& a, const string& n ) ;
  5. : _title(t), _authors(a), _isbn(n) { /* ... */ }
  6. string title() const { return _title ; }
  7. list<string> authors() const { return _authors ; }
  8. string isbn() const { return _isbn ; }
  9. // ...
  10. private:
  11. string _title ;
  12. list<string> _authors ;
  13. string _isbn ;
  14. // ...
  15. };
  1. struct book // less encapsulated, not insulated
  2. // most efficient (no copy of objects)
  3. {
  4. book( const atring& t, const list<string>& a, const string& n )
  5. : _title(t), _authors(a), _isbn(n) { /* ... */ }
  6. const string& title() const { return _title ; }
  7. const list<string>& authors() const { return _authors ; }
  8. const string& isbn() const { return _isbn ; }
  9. // ...
  10. private:
  11. string _title ;
  12. list<string> _authors ;
  13. string _isbn ;
  14. // ...
  15. };
;
Last edited by vijayan121; Sep 25th, 2007 at 11:03 pm.
Reply With Quote Quick reply to this message  
Reply

This thread is more than three months old.
Perhaps start a new thread instead?
Message:




Views: 1572 | Replies: 3
Thread Tools Search this Thread



Tag cloud for C++
About Us | Contact Us | Advertise | DaniWeb | Acceptable Use Policy | RSS Feed

©2003 - 2009 DaniWeb® LLC