Posted by
Vadim Ogranovich-3 on
Oct 28, 2002; 3:51pm
URL: http://quantlib.414.s1.nabble.com/call-for-void-constructors-tp10165p10166.html
>too much :-)) consider writing a function which given option
> characteristics
> >returns the most efficient pricer for that option, e.g.
> >
> > SingleAssetOption * getMostEfficientPricer(...).
> >
> > Without default constructors the argument list of the
> >function must include all parameters possibly needed by
> actual constructors
> >(fat parameter list). This is certainly not good as this
> list is likely to
> >change when you add new pricers or add parameters to the old
> constructors.
>
> I'm not entirely following you here. Won't you have the same problem
> with init(), i.e., won't init() suffer from the same
> fat-parameter-list problem? And if not, how will you know which kind
> of pricer was returned so that you can pass the right parameter list
> to init()? All you will get is a pointer to the base class...
Good point. Indeed, it is hard to imagine a scenario where one uses
getMostEfficientPricer() alone without immediately initializing the returned
pointer (using dynamic_cast, of course). After your comments I don't
consider the getMostEfficientPricer example very illustrative anymore.
Still, it would be nice to come up with a design that allows such a function
and any such design will probably require default constructors.
Thanks, Vadim
--------------------------------------------------
DISCLAIMER
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.
E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.
NOTICE REGARDING PRIVACY AND CONFIDENTIALITY
Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications.