Re: QwtSymbol passed as const pointer in QwtPlotCurve
Brought to you by:
rathmann
From: David S. <David_Stranz@MassSpec.com> - 2011-10-27 14:01:15
|
Hi Uwe, The derived symbols problem is a good argument, and I agree that it is difficult to store a copy of a derived instance when all you know about is the base class, except to use a pointer. References and clone() methods are awkward. I also think I understand what you are trying to say by using the "const QwtSymbol *" argument to setSymbol(): you are trying to tell the programmer that he can set the symbol to look exactly the way he wnats, and QwtPlotCurve will not change that. However, I think the appropriate way to do that is through documentation, not to use an unusual argument passing convention. As I said in an earlier e-mail, *taking ownership* after passing a const pointer is the problem. In the Qt world, that does not happen. In all cases where a Qt object takes ownership, a pointer is passed as non-const, and the programmer understands that he is giving the pointer away. Experience and documentation usually tell the programmer that important properties of the passed object will not be changed in a harmful way. So, I think if your intent is to make things more clear for programmers, then you should try to be consistent with what these programmers expect from other parts of Qt. Best regards, David _______________________________________________________________ David Stranz, Ph.D. david_stranz@MassSpec.com Sierra Analytics, Inc. 5815 Stoddard Road, Suite 601 Modesto, CA 95356 Tel: (209) 545-8508 http://www.massspec.com _______________________________________________________________ On 10/26/2011 11:13 PM, Uwe Rathmann wrote: > On 10/26/2011 08:37 PM, Hendrik Vennekate wrote: > >> My -- again, naive -- guess would be that it >> is too expensive to copy a symbol? And if so, my next question would be: is >> it really? > > The difference between a symbol and a pen is, that a symbol might be > inherited to overload the drawSymbols method - for having individual > symbols. > > In Qwt 5.x the symbol is indeed passed as reference ( not as pointer ) > and copied internally. But to make this work with derived symbols the > derived symbol class had to overload and reimplement QwtSymbol::clone() > as well. > > While this techinique results in very obvious APIs in terms of > ownership, it was simply not understood by the application developers. > Problems with what happens to QwtData ( using the same type of API ) was > one of main issues. > > So in the end my conclusion was, that the ownership problem is less > important, than these not-understood virtual clone/copy methods - even > if I still prefer the Qwt 5.x type of API myself. > > Uwe > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > qwt-interest mailing list > qwt...@li... > https://lists.sourceforge.net/lists/listinfo/qwt-interest > > |