home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12428 < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.4 KB  |  99 lines
  1. Xref: sparky comp.lang.c++:12428 comp.object:3228 comp.databases:6155
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!seunet!appli!niklas
  3. From: niklas@appli.se (Niklas Hallqvist)
  4. Newsgroups: comp.lang.c++,comp.object,comp.databases
  5. Subject: Re: A POET Tutorial
  6. Keywords: OODBMS, C++, POET
  7. Message-ID: <2008@appli.se>
  8. Date: 14 Aug 92 07:44:36 GMT
  9. References: <TCZ5DU@netmbx.netmbx.de> <9222615.24974@mulga.cs.mu.OZ.AU> <HH150DN@netmbx.netmbx.de>
  10. Followup-To: comp.lang.c++
  11. Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN
  12. Lines: 85
  13.  
  14. jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
  15.  
  16. >fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  17.  
  18. >>I have a couple of questions regarding Jonathan Robie's posting:
  19.  
  20. >>>      objbase.Close();    
  21. >>>      objbase.DisConnect();
  22.  
  23. >>Why aren't Close() and DisConnect() automatically called by the
  24. >>destructor?
  25.  
  26. >Each of these returns error codes which the programmer might want
  27. >to test and respond to.
  28.  
  29. It's true that you should provide means for a user to intercept errors
  30. but making resource deallocation explicit just for this may introduce
  31. errors instead.  The programmer might easily forget such a deallocation.
  32. Studies have shown that almost all non-trivial programs developped without
  33. a debugging malloc leaks memory, so it's not an uncommon error.  How should
  34. it be done then?  Well, one way is to do what Bjarne did with "new",
  35. introduce an error_handler pointer which the user can direct to his own code,
  36. another will be: use exceptions.  But beware... the latter can really
  37. surprise you in destructor contexts like these.  I'd go for the error_handler
  38. to start with.
  39.  
  40. >>>    PersonAllSet*    allPersons = new PersonAllSet("objbase");
  41. >>>    Person*    thisPerson;
  42. >>>
  43. >>>    allPersons->Seek(0, PtSTART);
  44. >>>    while (allPersons->Seek (1, PtCURRENT) == 0)
  45. >>>    {
  46. >>>    allPersons->Get(thisPerson);
  47. >>>    thisPerson->DoSomething();
  48. >>>    allPersons->Unget(thisPerson); // deletes the object if nobody 
  49. >>>                                  // else is using it.
  50. >>>    }
  51. >>>    delete allPersons;
  52. >>>
  53. >>>[...]
  54. >>>Note that we call Unget() when we are done with the object.  Every 
  55. >>>object you read takes up memory, so you should get into this habit.
  56.  
  57. >>Again, weren't destructors invented so that we wouldn't have to rely
  58. >>on programmers habits?
  59.  
  60. >What destructors are you talking about?  The destructor for allPersons
  61. >is not a good candidate, since it may sit around for a long time
  62. >creating objects that you really don't want to keep in memory until
  63. >the set is deleted, and using this destructor would make us keep
  64. >track of all loaded objects in the allPersons set.
  65.  
  66. >The destructor for the object is also not a great candidate since
  67. >it depends on programmer's habits just as much as the Unget() and
  68. >has different semantics.
  69.  
  70. I think he was thinking of an auxiliary resource allocator object.
  71. Something along the lines:
  72.  
  73. class PersonMapper {
  74.   PersonAllSet* s;
  75.   Person* p;
  76. public:
  77.   PersonMapper(PersonAllSet* a_s, Person* a_p) : s(a_s), p(a_p)
  78.     { s->Get(p); }
  79.   ~PersonMapper()
  80.     { s->UnGet(p); }
  81. };
  82.  
  83. Then the loop may look like:
  84.  
  85. while (allPersons->Seek (1, PtCURRENT) == 0)
  86. {
  87.   PersonMapper pmap(allPersons, thisPerson);
  88.   thisPerson->DoSomething();
  89. }
  90.  
  91. Comments?
  92.  
  93. Niklas
  94. -- 
  95. Niklas Hallqvist    Phone: +46-(0)31-40 75 00
  96. Applitron Datasystem    Fax:   +46-(0)31-83 39 50
  97. Molndalsvagen 95    Email: niklas@appli.se
  98. S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
  99.