problem with microsoft C compiler doesn`t accept things gcc does,how to solve? (encoding)

[Michael Reichenbach]

Here is the example code.

int main(int argc, char *argv[])
{
string Result;
WIN32_FIND_DATA daten;
HANDLE h = FindFirstFile(TEXT("c://test"), &daten);
system("PAUSE");
return EXIT_SUCCESS;
}

It works fine with DevCpp and gcc.

The error with microsoft C compiler is that he can`t convert from string
to LPCSTR.

I think the problem is inside the encoding, ansi, unicode, ... Found
some ways to avoid this error but all are not very awesome.

Please tell me the best way to solve this.

 

[Victor Bazarov]

Here is the example code.

"Example"? Of what?

int main(int argc, char *argv[])

You're not using 'argc' or 'argv' in your code here, why declare them?

{
string Result;

'string' is undefined.

WIN32_FIND_DATA daten;

'WIN32_FIND_DATA' is undefined.

HANDLE h = FindFirstFile(TEXT("c://test"), &daten);

'HANDLE' is undefined. 'FindFirstFile' is undefined. 'TEXT' is
undefined.

system("PAUSE");
return EXIT_SUCCESS;
}

It works fine with DevCpp and gcc.

I doubt that.

The error with microsoft C compiler is that he can`t convert from
string to LPCSTR.

By "string" do you mean the standard 'string' type? Then yes, there
is no such conversion (even if by 'LPCSTR' you mean 'char const*').

I think the problem is inside the encoding, ansi, unicode, ... Found
some ways to avoid this error but all are not very awesome.

Please tell me the best way to solve this.

To solve WHAT?

V

 

[Default User]

Here is the example code.

int main(int argc, char *argv[])
{
string Result;
WIN32_FIND_DATA daten;
HANDLE h = FindFirstFile(TEXT("c://test"), &daten);
system("PAUSE");
return EXIT_SUCCESS;
}

It works fine with DevCpp and gcc.

That's odd, with gcc I get:

gcct.c: In function `main':
gcct.c:3: error: `string' undeclared (first use in this function)
gcct.c:3: error: (Each undeclared identifier is reported only once
gcct.c:3: error: for each function it appears in.)
gcct.c:3: error: parse error before "Result"
gcct.c:4: error: `WIN32_FIND_DATA' undeclared (first use in this
function)
gcct.c:5: error: `HANDLE' undeclared (first use in this function)
gcct.c:7: error: `EXIT_SUCCESS' undeclared (first use in this function)

The error with microsoft C compiler is that he can`t convert from
string to LPCSTR.

I think the problem is inside the encoding, ansi, unicode, ... Found
some ways to avoid this error but all are not very awesome.

You obviously haven't posted the real code.



Brian

 

[Michael Reichenbach]

Ok. You got me. It`s was not the real code. I always try to cut down
my problem to a minimum so it`s more easy to figure out.

Here is a new example code. I tested it. It works in DevCpp but not in
Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;
}

 

[BobR]

Here is the example code.

int main(int argc, char *argv[]){

// > string Result; // not defined, not used!

WIN32_FIND_DATA daten;
HANDLE h = FindFirstFile(TEXT("c://test"), &daten);
system("PAUSE");
return EXIT_SUCCESS;
}
It works fine with DevCpp and gcc.
Nope!

The error with microsoft C compiler is that he can`t convert from string
to LPCSTR.

std::string Hi( "Hello" );
LPCSTR pHi = &Hi.at(0); // pick one
char const *pHi2 = &Hi.at(0);
LPCSTR pHi3 = Hi.c_str();
..... etc.

I think the problem is inside the encoding, ansi, unicode, ... Found
some ways to avoid this error but all are not very awesome.
Please tell me the best way to solve this.

#include <iostream>
#include <fstream>

int main(){
std::ifstream in( "c:/test" );
if( not in.is_open() ){
std::cout<<"File not found!\n";
}

 

[sun1991]

std::string Hi( "Hello" );
LPCSTR pHi = &Hi.at(0); // pick one
char const *pHi2 = &Hi.at(0);
LPCSTR pHi3 = Hi.c_str();

Is it right? I thought Hi.c_str() returns a temporary c-string, it
will be gone when pHi3 try to dereference it?

 

[=?ISO-8859-15?Q?Erik_Wikstr=F6m?=]

Ok. You got me. It`s was not the real code. I always try to cut down
my problem to a minimum so it`s more easy to figure out.

Here is a new example code. I tested it. It works in DevCpp but not in
Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;
}

1. Quote the text you are replying to.

2. In what way does it not work in Visual Studio (what version of VS by
the way?), does it kick you in the face or what. Post the error messages
or whatever you get.

See http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8 for
more info on what to include in your posts.

 

[Bo Persson]

sun1991 wrote:
:::: The error with microsoft C compiler is that he can`t convert
:::: from string to LPCSTR.
:::
::: std::string Hi( "Hello" );
::: LPCSTR pHi = &Hi.at(0); // pick one
::: char const *pHi2 = &Hi.at(0);
::: LPCSTR pHi3 = Hi.c_str();
:: Is it right? I thought Hi.c_str() returns a temporary c-string, it
:: will be gone when pHi3 try to dereference it?

It returns a pointer to a C-string (which might be a copy of Hi's
content). The pointer is valid as long as Hi isn't potentially
modified.



Bo Persson

 

[Zachary Turner]

Ok. You got me. It`s was not the real code. I always try to cut down
my problem to a minimum so it`s more easy to figure out.

Here is a new example code. I tested it. It works in DevCpp but not in
Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;



}- Hide quoted text -

- Show quoted text -

Do you have UNICODE (or maybe it's _UNICODE, I always forget)
defined? There is no way that code should fail under windows unless
FindFirstFile is expecting a wide character string, and it shouldn't
expect a wide string unless you have _UNICODE or UNICODE defined.

See if the following works:
int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile(L"c://test", &FindFileData); //notice
the L
system("PAUSE");
return EXIT_SUCCESS;
}

Venturing into off-topicness, but assuming this fixes it, one possible
reason it works with one compiler but not the other could be that
you're defining the preprocessor symbol through your project settings
(Project -> Project Propert -> C++ -> Preprocessor), which obviously
GCC doesn't know about.

The way windows functions work is that there's always 2 versions of
most WinApi functions. One ends with an 'A' and expects char*, the
other ends with a 'W' and expects wchar_t*. Then, based on the value
of various preprocessor symbols, a version of every function with
neither A nor W is #defined to the A or W version. So if you have
UNICODE defined, FindFirstFile actually is FindFirstFileW(wchar_t*,
WIN_32_FIND_DATA*), and if you don't have UNICODE defined,
FindFirstFile actually is FindFirstFileA(char*, WIN32_FIND_DATA*).
The same is true for many other functions as well.

 

[Default User]

Ok. You got me. It`s was not the real code. I always try to cut
down my problem to a minimum so it`s more easy to figure out.

That's a good idea, but what you post has to be a complete program.

Here is a new example code. I tested it. It works in DevCpp but not
in Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;
}

This compiled on gcc?


gcct.c:2:21: windows.h: No such file or directory
gcct.c:7: warning: data definition has no type or storage class
gcct.c:8: error: `FindFileData' undeclared here (not in a function)
gcct.c:8: error: initializer element is not constant
gcct.c:8: warning: data definition has no type or storage class
gcct.c:9: error: parse error before string constant
gcct.c:9: warning: data definition has no type or storage class




Brian

 

[sun1991]

sun1991 wrote:

:::: The error with microsoft C compiler is that he can`t convert
:::: from string to LPCSTR.
:::
::: std::string Hi( "Hello" );
::: LPCSTR pHi = &Hi.at(0); // pick one
::: char const *pHi2 = &Hi.at(0);
::: LPCSTR pHi3 = Hi.c_str();
:: Is it right? I thought Hi.c_str() returns a temporary c-string, it
:: will be gone when pHi3 try to dereference it?

It returns a pointer to a C-string (which might be a copy of Hi's
content). The pointer is valid as long as Hi isn't potentially
modified.

Bo Persson

Well, I did a little experiment:

int _tmain(int argc, _TCHAR* argv[])
{
{
std::string s("I'm a test string");
const char* ptr = s.c_str();
s = "Another test string";

printf("%s\n", ptr);

}
system("pause");
return 0;
}

And the result is: Another test string
---
So what I said above was wrong, looks like it actually returns a RAW
const char* ptr, point to the internal buffer of string. I don't think
c_str() will create a copy, if so, who should handle the delete action
on this copy?

Thanks!

 

[Jim Langston]

Ok. You got me. It`s was not the real code. I always try to cut down my
problem to a minimum so it`s more easy to figure out.

Here is a new example code. I tested it. It works in DevCpp but not in
Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;
}

This doesn't compile in MS VC++ .net 2003 without proper compile switches:

#include <windows.h>

int main()
{
}

Try a vc newsgroup.

 

[Bo Persson]

sun1991 wrote:
::: sun1991 wrote:
:::
::::::: The error with microsoft C compiler is that he can`t convert
::::::: from string to LPCSTR.
::::::
:::::: std::string Hi( "Hello" );
:::::: LPCSTR pHi = &Hi.at(0); // pick one
:::::: char const *pHi2 = &Hi.at(0);
:::::: LPCSTR pHi3 = Hi.c_str();
::::: Is it right? I thought Hi.c_str() returns a temporary c-string,
::::: it will be gone when pHi3 try to dereference it?
:::
::: It returns a pointer to a C-string (which might be a copy of Hi's
::: content). The pointer is valid as long as Hi isn't potentially
::: modified.
:::
::: Bo Persson
::
:: Well, I did a little experiment:
::
:: int _tmain(int argc, _TCHAR* argv[])
:: {
:: {
:: std::string s("I'm a test string");
:: const char* ptr = s.c_str();
:: s = "Another test string";
::
:: printf("%s\n", ptr);
::
:: }
:: system("pause");
:: return 0;
:: }
::
:: And the result is: Another test string
:: ---
:: So what I said above was wrong, looks like it actually returns a
:: RAW const char* ptr, point to the internal buffer of string. I
:: don't think c_str() will create a copy, if so, who should handle
:: the delete action on this copy?

The standard allows c_str to return a pointer to the string's internal
buffer, or to some other buffer. That is up to the implementation.
There is no explicit requirement to have an internal buffer, in the
first place. .-)

After you modify s, the ptr is no longer valid, so using it in printf
is undefined. Anything could happen!

If c_str would return a pointer to some other buffer, the string class
would be required to somehow manage that. In practice, this doesn't
happen as all known implementations have an internal buffer, and
returns a pointer to it. In the next edition of the standard, C++09,
this will most likely be required.


Also, if you assign a much longer string to s, it might have to
reallocate the buffer and you ptr will definitely point into nowhere.


Bo Persson

 

[joe]

Ok. You got me. It`s was not the real code. I always try to cut down
my problem to a minimum so it`s more easy to figure out.

Here is a new example code. I tested it. It works in DevCpp but not in
Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;



}- Hide quoted text -

- Show quoted text -

You do realize that "C://test" is an illegal path, don't you? Did you
perhaps mean "C:\\test" ? Or possibly "C:/test" ?

I can believe that gnu has some broken path translation layer blindly
converting '/'s to '\'s so that may explain why it works under gnu and
not VC.

joe

 

[Zachary Turner]

That's a good idea, but what you post has to be a complete program.




This compiled on gcc?

gcct.c:2:21: windows.h: No such file or directory
gcct.c:7: warning: data definition has no type or storage class
gcct.c:8: error: `FindFileData' undeclared here (not in a function)
gcct.c:8: error: initializer element is not constant
gcct.c:8: warning: data definition has no type or storage class
gcct.c:9: error: parse error before string constant
gcct.c:9: warning: data definition has no type or storage class

Brian

Sorry, but now you're just being stupid. There's two possibilities
here.

1) You are on an operating system other than Windows, in which case
you have got to be a complete idiot to think that #include <windows.h>
will work
2) You are on windows, in which case you have got to be a complete
idiot to not know how to compile programs for windows.

Please point me to the location in the FAQ that says that every code
fragment people post must be a complete working program, and compile
on every theoretical combination of platform and compiler.

If you're not smart enough to figure out that a) the program applies
to Windows only, and b) how to use the -I option of GCC, then perhaps
you aren't qualified to answer questions about C++ in the first place.

 

[Victor Bazarov]

That's a good idea, but what you post has to be a complete program.




This compiled on gcc?

gcct.c:2:21: windows.h: No such file or directory
gcct.c:7: warning: data definition has no type or storage class
gcct.c:8: error: `FindFileData' undeclared here (not in a function)
gcct.c:8: error: initializer element is not constant
gcct.c:8: warning: data definition has no type or storage class
gcct.c:9: error: parse error before string constant
gcct.c:9: warning: data definition has no type or storage class

Brian

Sorry, but now you're just being stupid. There's two possibilities
here.

1) You are on [..]

It does not matter what the possibilities are. The program is OS-
specific and the alleged behaviour is compiler-specific, so there is
no way to answer it from the language point of view. The FAQ does
contain a list of suggested newsgroups to post to to have platform-
and/or compiler-specific questions answered.

V

 

[joe]

Ok. You got me. It`s was not the real code. I always try to cut down
my problem to a minimum so it`s more easy to figure out.

Here is a new example code. I tested it. It works in DevCpp but not in
Visual Studio.

#include <stdlib.h>
#include <windows.h>

int main()
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind = FindFirstFile("c://test", &FindFileData);
system("PAUSE");
return EXIT_SUCCESS;

I am probably stating the obvious, but "c://test" isn't a valid path.
Now, "c:\\test" or "c:/test" is, but I don't know of anywhere that two
forward slashes are valid.

I never did see where you defined what doesn't work meant though.

joe

 

[Zachary Turner]

Sorry, but now you're just being stupid. There's two possibilities
here.

1) You are on [..]

It does not matter what the possibilities are. The program is OS-
specific and the alleged behaviour is compiler-specific, so there is
no way to answer it from the language point of view. The FAQ does
contain a list of suggested newsgroups to post to to have platform-
and/or compiler-specific questions answered.

I agree, but please understand that the fact that people are posting
to a newsgroup in the first place can -sometimes- (not always, but
sometimes) be an indicator that the person posting the question is not
exactly an expert on the topic they're posting about. In such cases,
it is very easy for someone to misunderstand the problem and think the
issue lies with something else. Rather than degrade such people and
intentionally toy with them, either cut to the chase and tell them to
post in a different group, or just answer the question.

In this case, it appears to have been a legitimate mistake. Something
compiled with gcc but not visual c. To someone who has very little
experience with windows programming, this can just as easily have been
a) a bug in visual c, b) a bug in gcc (it wasn't supposed to compile
but gcc accepted it anyway), or c) a platform specific problem. In
fact, for someone who is beginner to mid level, c may not even be an
apparent choice at first.