Re: Reentrancy issue
On Sun, 27 Jan 2008 13:10:19 -0800, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
I disregard any effort MS may or may not have done for making the CString
cast unnecessary. Obviously they do not stand behind that effort, as per
the article cited by Giovanni.
Hmmm, that would seem to obligate you to respect all documentation, yet
from past discussions, I know you don't. For all your talk of "real life",
in the past, you've rejected rules that matter, and now, you're honoring
one that doesn't. Just an observation. :)
I agree that not casting the CString is not currently a problem, but
improper comparison of a BOOL could currently cause problems.
OK!
However, I've not seen this in real life.
Oh. I understand you haven't seen this. You said that last time. What you
mean is, "So far, I've not observed a problem with the BOOL thing in my own
Windows programming." See my last message to understand why your "real
life" experience represents but a tiny sample of reality, and note also
that at least two people in this thread have said they've had problems with
the BOOL thing.
So the bottom line for me is: I think it is
splitting hairs about which is more likely to cause a problem in real life.
One is clearly more likely to cause problems in "real life". That's what I
established in my last message, and Joe and Tom have confirmed it in their
own "real lives". I don't get why you've been trying to equate the BOOL
thing with the CString issue throughout this thread. The two aren't related
at all, and the result of saying they're equivalent is a number of people
explaining to you that they're not. Now you're characterizing this as
"splitting hairs". Round and round it goes!
The bottom line is if they are causing a problem, they need to be fixed,
otherwise, making them optimal can wait until it is convenient to cleanup
the code.
"Don't fix what ain't broke." The problem is determining what's "broke" and
what isn't, and as I explained last time, and Joe and Tom added in their
own messages, you can't make a reliable determination of that for the BOOL
thing. You can for the CString issue. If you don't fix the BOOL thing now,
you are at risk in "real life", which is far bigger than your own personal
experience.
Since it is splitting hairs, it remains hypocrtical to call one
naive while blissfully practicing the other.
Although it completes your (false) syllogism, no one's suggested
"blissfully practicing the other". Remember, you're talking to the guy who
filed a feedback item on the ellipsis issue a couple of years ago, which if
implemented, would "penalize" everyone relying on the CString hack with a
warning (assuming MS didn't go to still more heroics to suppress the
warning for CString as I described in my reply to Giovanni):
Compiler should warn about passing objects of non-POD types to the ellipsis
Opened 6/13/2005
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98899
<q>
Proposed Solution
VC++ should warn about passing objects of non-POD class types to the
ellipsis. While MFC's CString may have been designed to permit this, the
current documentation frowns on the practice:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Strings3a_CString_Operations_Relating_to_C2dStyle_Strings.asp?frame=true
"it is essential that you use an explicit type cast when passing a CString
object to a function that takes a variable number of arguments."
Thus, implementing this warning will reinforce the MFC documentation in
addition to helping all the non-CString cases.
</q>
Of course, my real concern was for types for which it actually matters
(i.e. "real life"), such as std::string; I was surprised and amused to find
the CString documentation and included it more for "shock value" than
anything, since it didn't apply to x86 at least and contradicted
longstanding common practice. To this day, it doesn't apply to x86. I've
been careful all along to qualify this by saying "x86", because for all I
know, the 64-bit compiler may do things differently, and if so, the CString
hack might not work. In that case, the documentation would apply, and it
would make implementation of the warning that much more desirable.
As for the "relative naivet9" of the two things, which you are talking
about once again, FWIW, the BOOL thing is *by far* the more naive of the
two. It has an *ancient* history, and you know what? I could pass a CString
or std::string to the ellipsis not because I'm "naive", but because I made
a mistake, which is what motivated me to create my feedback item. But I
could never write (b == TRUE) by mistake; I could write it only if I didn't
know better and thus were "naive", to put it in the terms you've been
using.
--
Doug Harrison
Visual C++ MVP