[sword-devel] C++ design question

[Torsten Uhlmann]

Thanks for your kind replies!
This gave me an overview of my options and how to do it!

BTW, we still need C++ programmers :)

Thanks again!

>>>>> "Paul" == Paul Gear <paulgear@bigfoot.com> writes:

    > Scott Davis wrote:
    >> ...  2) returning by pointer CData *getText() gets away from the
    >> problems of returning by copy, but introduces its own problems.
    >> If this is actually CData* SomeClass::getText() and SomeClass is
    >> simply returning a pointer to internal data that it takes care
    >> of, that will work well.  But declare it as const CData
    >> *getText() so that you can modify or delete SomeClass's internal
    >> data.  If this is not the case, and getText would have to
    >> dynamically create the CData object and then return it, you are
    >> asking for trouble.  Not a problem as long as you **DOCUMENT
    >> STRONGLY**, but you will need to make sure that the CData objects
    >> are deleted by the calling code.
    >> 
    >> 3) using a reference.  Probably the best way to do it in htis
    >> case, if I understand the problem correctly.  Create an empty
    >> CData object and pass it to the getText() method.  getText fills
    >> the object and returns it.  Safe. Easy.  No mess.  Just my 2
    >> cents, of course.  ...  On 21 Jan 2000, Torsten Uhlmann wrote:
    >> 
    >> > ...  > I have created a class CData which will hold the result
    >> of a query to a > module, module type, data type and used key, so
    >> it can hold qiet some > data. I don't know what is the proper way
    >> of returning such an > object. Possibilities are: > > CData
    >> getText(key) or > getText(key, CData&) or > CData *getText(key) >
    >> > In the last one the caller has to destroy the CData object
    >> itself.  > I want to do it right this time so I would like you to
    >> give me advise!  > > Thanks for your response...

    > Scott is definitely right about the 'no correct answer' part.  I
    > would agree with him that returning by copy is most likely not an
    > option.

    > There are some good and bad points about pointers and references.
    > Pointers must have their memory management handled manually.
    > i.e. 'new' and 'delete' must be explicitly called.  This is OK, as
    > long as you decide (and document, as Scott said) who does the
    > creating and destroying.  I think it is usually easiest to let the
    > client code do all the memory management, and just pass the
    > pointers in and out of the class.  So in your example, i would
    > use: bool getText( key, CData *result ) where the return code
    > indicates success or failure (if appropriate), and the result is
    > stored in CData.  Another issue with pointers is that they look
    > uglier in your code (assuming you think 'foo->func()' looks uglier
    > than 'foo.func()' as i do :-).

    > References look much cleaner in the code, and have the feature
    > that once assigned, they cannot be changed.  i.e. The following
    > code is illegal: Foo &foo; Foo bar; foo = bar; To assign 'foo' to
    > point to 'bar', you must do: Foo bar; const Foo &foo( bar );
    > Whether this is an advantage or not depends on what you want to
    > do.  If you need to reassign it, you must use pointers.

    > Another issue with references is that it is sometimes unclear when
    > their constructors and (more importantly) destructors get called.
    > Whether or not this is an issue probably depends on how
    > significant your constructors and destructors are.  i.e. Will they
    > screw things up if they are called at the wrong time?

    > Overall, i'd suggest using references in preference to pointers,
    > but be aware of the issues.  And as Scott said, make sure you get
    > your const-ness right!  -- Paul --------- "He must become greater;
    > i must become less." - John 3:30 http://www.bigfoot.com/~paulgear

-- 

best regards,
Torsten Uhlmann

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TUhlmann@gmx.de
TUhlmann@debis.com

http://www.tuhlmann.purespace.de
http://www.bibletime.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wise men still seek him!