How to: optional CString parameter
in [MFC]
|
From: Giovanni Dicanio on 5 May 2008 03:42 "Serge Wautier" <serge(a)wautier.nospam.net> ha scritto nel messaggio news:eTyYdnnrIHA.5872(a)TK2MSFTNGP04.phx.gbl... > In addition, if your function contains > > CString myString(pszInputStr); > > -> duplicates the string buffer. Expensive & useless! I was missing that: if in your function body you need to use CString features on the input parameter, I agree with you. But if I pass a LPCTSTR, I'm going to manage it using C-like string functions like _tcslen() to get its length. If I needed CString:: methods on input string inside function body, I would consider using 'const CString &' as parameter, too. Giovanni
From: Giovanni Dicanio on 5 May 2008 03:48 "Giovanni Dicanio" <giovanni.dicanio(a)invalid.com> ha scritto nel messaggio news:uqZYBPorIHA.1952(a)TK2MSFTNGP05.phx.gbl... > But if I pass a LPCTSTR, I'm going to manage it using C-like string > functions like _tcslen() to get its length. BTW: and I know that _tcslen() is a O(N) operation, so if I need the string length multiple times, I cache it in a local variable. Giovanni
From: David Wilkinson on 5 May 2008 08:16 Doug Harrison [MVP] wrote: > Though not quite the same as NULL, you could use: > > virtual CString Get( > CString strURL, // If you don't modify, use a const reference. > const CString& strErrorMsg = CString()); > > But I wouldn't use default parameters with a virtual function. A better > approach would be: > > CString Get( > CString strURL, > const CString& strErrorMsg = CString()) > { > return Get_impl(strURL, strErrorMsg); > } > > virtual CString Get_impl( > const CString& strURL, > const CString& strErrorMsg); > > The other reason to use this technique is to avoid overloading virtual > functions, which reduces the burden on derived classes that want to > override the virtual function. <snip> Doug: Yes, I have learned over the years that both overloading and default parameters for virtual methods are best avoided. Your technique avoids both. The virtual method can (should?) be private in this situation. -- David Wilkinson Visual C++ MVP
From: Doug Harrison [MVP] on 5 May 2008 12:18 On Mon, 05 May 2008 08:16:53 -0400, David Wilkinson <no-reply(a)effisols.com> wrote: >Yes, I have learned over the years that both overloading and default parameters >for virtual methods are best avoided. Your technique avoids both. The virtual >method can (should?) be private in this situation. I think usually they would be protected. While they're not part of the public interface, derived classes should be able to call them, in particular to call them statically. -- Doug Harrison Visual C++ MVP
From: Doug Harrison [MVP] on 5 May 2008 12:26
On Mon, 05 May 2008 02:26:20 -0400, Joseph M. Newcomer <newcomer(a)flounder.com> wrote: >or just do > >virtual CString Get(const CString & strULR, CString & strErrorMsg) > >and then have an overload > >virtual CString Get(const CString & strULR) > { > CString dummy; > return Get(strULR, dummy); > } While it's undesirable to overload virtual functions, that's actually better than using a default argument, because it localizes the dummy CString creation to the function body, instead of creating and destroying it at each and every call-site. (It's also necessary when strErrorMsg is a non-const reference, but I think that was a mistake in the interface.) -- Doug Harrison Visual C++ MVP |