|
The recent mention of something being wrongly defined as
just the first char of a string reminded me of a problem I saw when trying to
build a Unicode version on Windows so I went and had a look at it again and I think
that there are problems with several of our macros and their usage… For example: #define PORTNOTETRACE(section, text) \ PORTNOTE(section,text) \ TRACE(_T("PORTNOTE[" section "]: "
text)) If this is used with two ansi strings as follows: PORTNOTETRACE(“other”, “Blobby”) This expands to: PORTNOTE(“other”, “Blobby”) TRACE(_T("PORTNOTE[" “other” "]:
" “Blobby”)) But as _T(s) is defined as L ## s this expands to: TRACE(L"PORTNOTE[" “other” "]:
" “Blobby”) ...and the VC compiler errors about mismatched strings being
concatenated as only the first “PORTNOTE[“ string gets prefixed
with L. Why gcc usually works I’m not sure. Perhaps it
concatenates strings as part of the tokenisation (i.e. before the ## is handled)
or perhaps this case hasn’t been considered properly in the compiler and
the fact they are different char types is simply ignored causing incorrect
strings to be generated. I have “fixed” PORTNOTETRACE by putting _T()
around each of the items that are concatenated but unfortunately this also
affects all macros that expect to take ansi params (e.g. ENSURE etc) but
internally do a _T(param) to widen them. If these are called with
concatenated strings e.g. ENSURE(“Hello\n” “world”),
then it will fail. This happens quite a lot in quite a few places. Basically, I think we need to check every use of # and ## in
our macros and then document what type of string should be passed to each macro
and whether they can be called with concatenated strings (e.g. ENSURE expects a
single ANSI string). I have made quite a lot of changes (mostly to
ENSUREs and #pragma message because _LOCMSG_ is ANSI) but have not yet tested
them on linux. Could this explain the weird issue in CamArtControl? Gerry |