alfps@start.no (Alf P. Steinbach) wrote in message news:<3fd76684.363223203@News.CIS.DFN.DE>...[color=blue]
> On 10 Dec 2003 10:20:24 -0800,
aqweeva@seanet.com (Robert) wrote:
>[color=green]
> >In my code below, the Notify Constructor and Destructor is getting
> >called twice and it appears that a new Notify object is created on the
> >2nd call. The 2nd call is caused by this line below: pNotify = new
> >EMAILnotify; that lives in the Notification Constructor.[/color]
>
> Class Notification derives from Notify. The calling sequence is:
> (1) create a Notification object, which executes the Notify constructor,
> and then (2) executes the Notification constructor body, which (3)
> executes pNotify = new EMAILnotify, which (4) creates an EMAILnotify
> object, where EMAILnotify is derived from Notify, so that this creation
> (5) executes the Notify constructor for the EMAILnotify object, and (6)
> proceeds to execute the EMAILnotify constructor body.
>[/color]
Thanks for all the information and tips...
[color=blue][color=green]
> >...
> >
> >************************************************* *************
> >#include <iostream>
> >#include <string>
> >
> >using namespace std;
> >
> >class Notify[/color]
>
> This is a bad name for a class. A class doesn't "do" anything,
> unless it's a functor class. Which this isn't.
>[/color]
Agreed!...
[color=blue][color=green]
> >{
> >public:
> > Notify(void){ cout << "Constructing Notify: " << this << endl; }[/color]
>
> Style.
> 'void' as an argument list is a C'ism which you'd better forget.
>[/color]
Agreed!, that's what I get for cutting and pasting sample code.
[color=blue]
>[color=green]
> > virtual ~Notify(void){ cout << "Destructing Notify: " << this <<
> >endl; }
> > virtual void Send() = 0;
> >};[/color]
>
> Style.
> At least one empty line between class declarations is a good idea.
>[/color]
This was a post, need to keep it short.
[color=blue]
>[color=green]
> >class Notification : public Notify
> >{
> >public:
> > Notification(void){}
> > Notification(string sNotifyType);
> > virtual ~Notification(void);
> > void Send(){ pNotify->Send(); }
> >private:
> > Notify* pNotify;
> >
> >};[/color]
>
> Style.
> The definitions of the Notification member functions should appear
> here, before anything more. One "place" per class in the code.[/color]
Again, this was a post, the real code is in separate modules.
[color=blue]
> Design.
> Having a pNotify member doesn't seem to serve any useful purpose.
> Most probably you have tried to implement too much in one class.
>[/color]
pNotify as a member is vital in supporting the strategy pattern.
Please correct me if I'm wrong.
[color=blue]
>[color=green]
> >class EMAILnotify : public Notify
> >{
> >public:
> > EMAILnotify(void){}
> > virtual ~EMAILnotify(void){};
> > virtual void Send(){ cout << "Send() Email: " << this << endl; }
> >};
> >Notification::Notification(string sNotifyType)
> >{
> > if(sNotifyType == "EMAIL")[/color]
>
> Design.
> Don't identify types by strings (in general). Use symbolic constants
> if you absolutely have to. But even more to the point: don't identify
> types by data unless you really Really REALLY have to.
>[/color]
Agreed!, but then how would I identify a type at run time via
polymorphism?
[color=blue][color=green]
> > pNotify = new EMAILnotify; // Causes 2nd Constructor call
> >}
> >Notification::~Notification(void)
> >{
> > if( NULL != pNotify )[/color]
>
> Coding.
> No need to check for NULL.
>[/color]
Yep!
[color=blue][color=green]
> > delete pNotify;
> >}
> >
> >void main()[/color]
>
> C++ standard.
> 'void main' is not allowed. This is not a valid standard C++ program.
>[/color]
When I test sample code, no need to worry about Standards that would
not cause bugs...
[color=blue][color=green]
> >{
> > Notification* pNotification = new Notification("EMAIL");
> > pNotification->Send();
> > delete pNotification;[/color]
>
> Style.
> The above is not exception safe in any sense. Use a std::auto_ptr.
>[/color]
This is sample code, in the real program it is wrapped in a
try{}catch{}
[color=blue][color=green]
> >}[/color][/color]
Thanks again for your tips...
--Robert