Re: QwtSymbol passed as const pointer in QwtPlotCurve

[David S. <David_Stranz@MassSpec.com>]

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
>
>