FindFirstFile() and std::string

This is a discussion on FindFirstFile() and std::string within the Windows Programming forums, part of the Platform Specific Boards category; When I compile the following bit of code in VC++ 2008, I get the error, " error C2664: 'FindFirstFileW' : ...

  1. #1
    Registered User
    Join Date
    Aug 2006
    Posts
    43

    FindFirstFile() and std::string

    When I compile the following bit of code in VC++ 2008, I get the error, "error C2664: 'FindFirstFileW' : cannot convert parameter 1 from 'const char *' to 'LPCWSTR'"

    Code:
    ...
    WIN32_FIND_DATA data;
    HANDLE hFind;
    std::string path;
    path = "C:\\*.*";
    hFind = FindFirstFile(path.c_str(), &data);
    ...
    The same code would work in VC++ 6, where FindFirstFile took a LPCTSTR, and not a LPCWSTR. Casting to a LPCWSTR doesn't do the trick, so how do I make this work?

    Thank you in advance.

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,662
    Use WIN32_FIND_DATAA and FindFirstFileA.

    VS 2008 enables UNICODE by default for new projects I believe - which means "wide" API's are used instead ANSI API's.

    gg

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    Enter project options, set character set to multibyte. Then there's no need to use XXXA.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,662
    My preference is to use the explicit API. Otherwise, your code *should* (in my opinion) support both ANSI and UNICDOE API's. Something like:
    Code:
    ...
    WIN32_FIND_DATA data;
    HANDLE hFind;
    #ifdef UNICODE
    std::wstring path;
    #else
    std::string path;
    #endif
    path = TEXT("C:\\*.*");
    hFind = FindFirstFile(path.c_str(), &data);
    ...
    There's only one reason I can think of for coding in TCHARS - to support Windows 95, since it only supports ASCII API's.

    gg

  5. #5
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    There's certainly no downside to either method. Coding in tchars gives the flexibility to switch between ansi/unicode without code changes, if you just want to test something or for whatever reason.
    But the option in the config was meant to be used as the setting for what character set you are targeting, since everything in the header line up to match that setting.
    Explicit use, I think, is good for when you need to use an ansi function in a unicode app or the other way around.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21