Re: Is the following little function UNICODE-safe? ...

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

See below,..
On Wed, 26 Mar 2008 12:10:39 -0700 (PDT), ".rhavin grobert" <clqrq@xxxxxxxx> wrote:

On 26 Mrz., 19:22, "Doug Harrison [MVP]" <d...@xxxxxxxx> wrote:
On Wed, 26 Mar 2008 10:39:59 -0700 (PDT), ".rhavin grobert"

LPCTSTR CInfFile::ExtensionGetDefault() const {
static DWORD dwDefID;
dwDefID = CFZFile::IdentifierGetDefaults(TypeGet());
dwDefID &= 0x00FFFFFF;
return reinterpret_cast<char*>(&dwDefID);
}

That code is not going to compile in a Unicode build, where LPCTSTR is
const wchar_t*, because there is no standard conversion between char* and
wchar_t*. Moreover, you can't just cast a char* to a wchar_t*. You have to
convert narrow strings to wide strings and vice versa using functions like
MultiByteToWideChar and its counterpart, or, in some cases, you can use
CString for this.

i see...

In addition, this code is limited to three character
extensions and assumes it can store three characters in a DWORD, which is
not the case for Unicode and is an unwise, unnecessary practice no matter
how you look at it.

extensions it this env will allways be 3 "chars". allways.

In addition, both functions are equally inefficient.
For the second one to be more efficient, you'd have to initialize the
dwDefId variable when you declare it; that way,
CFZFile::IdentifierGetDefaults(TypeGet()) would be called only the first
time ExtensionGetDefault is called, modulo the inherent race condition in
multithreaded programs.

The simplest approach is to add a CString member to CInfFile.

a CString is simply *far* to big.
****
I would argue that this statement is nonsensical. Define "far too big"! Exactly how many
millions of these do you plan to return? Note: if it is not on the level of millions, I
seriously question the statement that it can be "too big"
****
i have just a single byte (returned
by member-fn TypeGet()) and static CFZFile::IdentifierGetDefaults()
returns a DWORD, consisting of (first byte [mask 0xFF00000]) version
of file (there will never be a reason for more that 255 versions in
that env) and a 3-byte id [mask 0x00FFFFFF] equal to the files default
ext. Now i need a very fast way to the following:
****
What does this have to do with returning a string? How long do you plan to store this
string, and how many millions of them are going to exist concurrently?
****

(1) convert the four chars into a four-byte-string by simply doing...

dwDefID &= 0x00FFFFFF;
****
This does seem to be a rather crude solution to a problem.
****

(2) somehow convert that already existent 'string' still known by the
compiler as a DWORD
into a LPCTSTR. without UNICODE, a ...

reinterpret_cast<char*>(&dwDefID);

...does the trick.
****
No it does not. It tells the compiler you are lying about the type, but it will NOT
create a Unicode string, not by any stretch of the imagination. And you are returning a
pointer to a local variable, which is a fatal design error, as I already pointed out.
****

If it's immutable, and you create multiple instances of CInfFile, you can probably
make it a static member, so there will be only one of them, and it will be
initialized at program startup.
****
This would be a disastrous design decision. You can take as a fundamental heuristic of
programming that creating a non-const static variable in a function and returning a
pointer to it is *always* a deep and fundamental design error, end of story. The number
of exceptions to this rule is so vanishingly small that it is not even worth considering.

every CInfFile may have its own extension out of 255 possibillities.
****
And why does CString not work, other than some unsupported allegation that a CString is
"far too big"?

You need to quantify WHY you think this is so, as I said above, tell me how many millions
of these you need to store. If the number cannot be expressed in millions, you are
probably wrong in any belief about size being relevant.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Is the following little function UNICODE-safe? ...
    ... static DWORD dwDefID; ... extensions and assumes it can store three characters in a DWORD, ... What does this have to do with returning a string? ... it's a static DWORD. ...
    (microsoft.public.vc.mfc)
  • Re: Is the following little function UNICODE-safe? ...
    ... static DWORD dwDefID; ... extensions and assumes it can store three characters in a DWORD, ... What does this have to do with returning a string? ... it's a static DWORD. ...
    (microsoft.public.vc.mfc)
  • Re: Is the following little function UNICODE-safe? ...
    ... static DWORD dwDefID; ... That code is not going to compile in a Unicode build, ... extensions and assumes it can store three characters in a DWORD, ... extensions it this env will allways be 3 "chars". ...
    (microsoft.public.vc.mfc)
  • Re: Moving from C++ to VC++
    ... Code conventions, MS typedef's that should be used (DWORD for example), and other things that accomplish the same ... An LPCWSTR if UNICODE is defined, ... Pointer to a constant null-terminated string of 16-bit Unicode characters. ...
    (microsoft.public.vc.language)
  • Re: Is the following little function UNICODE-safe? ...
    ... LPCTSTR CInfFile::ExtensionGetDefaultconst { ... static DWORD dwDefID; ... That code is not going to compile in a Unicode build, ...
    (microsoft.public.vc.mfc)