Re: Setting PropertySheet Title (Wizard mode)
Joseph M. Newcomer wrote:
John H. wrote:
passing small strings by reference vs. by
value. Arguments include
"this is probably premature
optimization" "the optimizing compiler will do this for you anyways"
If you think of it as optimization, it is probably the wrong reason.
Also from an interface perspective, I guess for this
example I landed on the "keep the interface simple".
No, an interface that is simple but is not correct is not a valid inteface. The use of
'const' captures the purpose of the interface. Once you have the const, it really doesn't
matter if you pass by reference or value; you have said somehting correct about your
intentions at the interface.
I can think of interfaces that have a simple form (non-const
parameters) and a more complex form (const correct parameters), and
both produce the same desired execution. Am I interpreting you right
to by saying that the one that captures "purpose" better is more
Since there is *only* pass-by-value in C and C++
("reference" or "pointer" are VALUES that are passed)
I was trying to use pass-by-value to mean situations where the value
that is copied is not a reference or pointer. For references or
pointers I will call that pass-by-reference.
I don't buy the arguments about
using it for pass-by-value. I believe based on my experience that the use of const
results in cleaner code that is more likely to be correct.
I am confused. Are you saying that you don't agree with the arguments
that I mentioned for const with pass-by-value, but that there are
other reasons (that you mentioned) to use const with pass-by-value?
Or are you saying that const is only useful with pass-by-reference and
not at all with pass-by-value?
And if you use Best Practice and use the public header file in your own compilation then
the compiler will complain about mismatched parameter types between the declaration and
I don't understand. Is "Best Practice" an option in the compiler or
an additional development tool? As far a I know, a conforming
compiler and at least a few versions of the VC compiler will know to
match the following declaration and definition:
// In the foo.h:
void print_x(int num_times);
// In the foo.cpp:
void print_x(int const num_times)
for(int i=0; i<num_times; ++i)
std::cout << 'x';
This is the idea I was trying to say when I said put const in the
definition but not the declaration. Here, from the caller's point of
view, it seems like an irrelevant detail on whether num_times is a
const parameter or not. The parameter is copied so whatever they
passed cannot be modified anyways. The function should produce the
same result either way. The fact that the implementation doesn't
modify num_times is really something only of interest to the
implementation. A implementation could in fact modify num_times and
still be correct, something like the following (untested):
void print_x(int num_times)
for(; num_times > 0; --num_times)
std::cout << 'x';
I think that using const in pass-by-value (as in pass a copy)
parameters has some merits. However looking at most existing code,
this seems like a rare practice.
CString ... manages
a reference count. If you try to do something to a string whose refcount is 1, it can use
move semantics because it has the one-and-only copy in hand. As you pass a CString around
by reference, the refcount is update and copy semantics will come into play when required.
It uses copy-on-write semantics (COW)...
Nice to know.
The real error was using a character array; that is always known to be bad practice in
such cases (and was a glaring bug in the example given!). In fact, the use of strcpy,
As this is an MFC forum, I agree with you, and it was a bad example.
Off-topic, I have been doing work lately in an embedded platform where
we don't have CString or std::string or smart pointers, and I got a
little too compfy with these less robust tools.