Re: [Crystal-cvs] SF.net SVN: crystal:[38394] CS/trunk/include/csutil/vararg.h

On Tue, Jul 17, 2012 at 4:22 AM, Eric Sunshine <[email protected]> wrote:
> On Tue, Jul 17, 2012 at 4:00 AM, res <[email protected]> wrote:
>> I have a third suggestion:
>> Only keep the methods taking a va_list virtual. Keep the ‘real’ vararg methods unconditionally defined, however have (force) them to be inline and non-virtual; they just call the va_list variant.
>> Thoughts, comments?
> In all of these cases, the vararg methods are being invoked via SCF
> interfaces, rather than on the implementing object. If we take
> this approach, it would mean implementing the non-virtual inline
> vararg variation within the SCF interface itself, thus these would no
> longer be "pure" interfaces. I don't personally see that as a big
> deal, so the approach is certainly feasible.

I have implemented this approach. It's cleaner than the va_call()
solution and requires less churn and less maintenance. If we are okay
with these few SCF interfaces being non-pure, I will finish polishing
the changes and commit.

Opinions?

-- ES

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/