C / C++ / MFC

2-Jul-06 21:51

Hi guys this is rocky.
I got stuck in a problem plz help me.

I want to read a text file which is having unciode charachters in C/C++.

i m using normaal fopen function but can't get the result fine..

here is the small peace of codeee

if ((fp = fopen("d:/GRCasual.txt", CFile::modeRead|CFile::typeBinary)) == NULL)
{
return 0;
}

while(!feof(fp))
{
/*fseek(fp,sizeof(char),SEEK_CUR); */
retbuf = fgets(buf, 200, fp);
}

thnx in advance guys ............
i m waitin for ur replies..........

Best Regards
Rocky

Don Box2-Jul-06 21:55

Don Box

2-Jul-06 21:55

Declare the "buf" parameter in fgets(buf, 200, fp) as wchar_t type.

Jubin Chawda
braindrain1@rediffmail.com
-----------------------------
Come online at:-
fitiyal@yahoo.com

Rocky Marrone2-Jul-06 22:05

2-Jul-06 22:05

i m gettin an exception that

error C2664: 'fgets' : cannot convert parameter 1 from 'wchar_t *' to 'char *'

what abt this

thnx in advance

Best Regards
Rocky

Viorel.2-Jul-06 22:15

2-Jul-06 22:15

Try fgetws instead of fgets.

(However it is unlikely that your second parameter of fopen will work).

Rocky Marrone2-Jul-06 22:19

2-Jul-06 22:19

Thnx for the reply first

thnx for giving me some time

here is the peice of code i m not getting the result

FILE* fp = NULL;
wchar_t* buf = (wchar_t*)malloc(sizeof(wchar_t) * 200);
wchar_t* retbuf = NULL;

if ((fp = fopen("d:/GRCasual.txt", "r")) == NULL) // opens the file
{
return 0;
}

while(!feof(fp))
{
/*fseek(fp,sizeof(char),SEEK_CUR); */
retbuf = fgetws(buf, 200, fp);
}

if( fp )
fclose(fp);
return 0;

Viorel.2-Jul-06 22:24

2-Jul-06 22:24

Instead of

if ((fp = fopen("d:/GRCasual.txt", "r")) == NULL)

try this:

if ((fp = fopen("d:\\GRCasual.txt", "rb")) == NULL)

I hope it helps.

Hamid_RT2-Jul-06 22:21

2-Jul-06 22:21

See OLE2A USES_CONVERSION;

whitesky

Rocky Marrone2-Jul-06 22:26

2-Jul-06 22:26

Sorry Guys but can't get the result with this also OLE2A USES_CONVERSION

plz help

thnx in advance

Rocky

Hamid_RT2-Jul-06 22:32

2-Jul-06 22:32

you said "cannot convert parameter 1 from 'wchar_t *' to 'char *" whats error? and i said use OLE2A

whitesky

Rocky Marrone2-Jul-06 22:49

2-Jul-06 22:49

Guys this is the code but cant read the unicode file...........
if there is any problem in it tell me i will solve it..........

FILE* fp = NULL;
wchar_t* buf = (wchar_t*)malloc(sizeof(wchar_t) * 200);
wchar_t* retbuf = NULL;

if ((fp = fopen("d:/GRCasual.txt", "r")) == NULL) // opens the file
{
return 0;
}

while(!feof(fp))
{
/*fseek(fp,sizeof(char),SEEK_CUR); */
retbuf = fgetws(buf, 200, fp);
}

if( fp )
fclose(fp);
return 0;

thnx in advance
regards
Rakesh

About Cd-rom?

Syouki_kou2-Jul-06 21:33

Syouki_kou

2-Jul-06 21:33

How could i judge the Cd-rom door's status?(open or closed). Pay attention to that here is Cd-rom not DVD-rom, I used the SCSI command "Mechanism Status" to get the dvd-rom door's status successfully, but it can't work on Cd-rom, so what should i do to fix this trouble? Smile | :)

Go go go, roger that. Enemy sighted!

Don Box2-Jul-06 21:52

Don Box

2-Jul-06 21:52

U look into DeviceIoControl() with IOCTL_STORAGE_EJECT_MEDIA as a second parameter.

Jubin Chawda
braindrain1@rediffmail.com
-----------------------------
Come online at:-
fitiyal@yahoo.com

Hamid_RT2-Jul-06 22:39

2-Jul-06 22:39

See CD Change Notifications[^] maybe it is some helpful to you

whitesky

Syouki_kou3-Jul-06 16:44

Syouki_kou

3-Jul-06 16:44

Thanks you all for your helpful infos, but all seems not work fine.
Is there a command of SCSI just as same as "mechanism status" command which can work on DVD-ROM?
Or some other helpful infos? Sniff | :^)

Hamid_RT3-Jul-06 18:34

3-Jul-06 18:34

And thisOpen or Close CD-ROM drive[^]

whitesky

strange linking error with operator overloading

Syouki_kou3-Jul-06 20:38

Syouki_kou

3-Jul-06 20:38

Thanks for your help, whitesky!
But I wonder if you really understand what I want to realize!
I just want to know the status of CD-ROM, it is opened or closed?
The MCI command can't work at all, I tried it before, and WM_DEVICECHANGE message also can't work. And I tried MMC command(APSI programming),but it can only work on DVD-ROM, do not work on CD-ROM! That's my trouble.

My original purpose is that if you right click the CD/DVD-ROM icon, the eject menuitem can take a little change for it can change to "Insert" if the door is already opened, and back to "eject" if the door is closed. For this, I must know the status of the door, it is closed or open?

One day a pretty girl asked me: "Do you think you are handsome?"."I don't think so!" She gave a slap in my face:"Why lying?"

George_George2-Jul-06 21:27

Re: strange linking error with operator overloading

2-Jul-06 21:27

Hello everyone,

I am meeting with a strange linking error regarding to operator overloading. I am creating a C++ static lib, and then linking it with a C application. Here is the error message and source codes,

I am using adapter.cpp, adapter.h, foo.cpp and foo.h to create a static lib called foo.lib, then link it with a C application (goo.c). There is no problem to generate the static lib foo.lib.

Any comments to solve this link error?

<br />
error LNK2019: unresolved external symbol "private: class FooNameSpace::Foo __thiscall FooNameSpace::Foo::operator=(long)" (??4Foo@FooNameSpace@@AAE?AV01@J@Z) referenced in function "private: __thiscall FooNameSpace::Foo::Foo(<br />
long)" (??0Foo@FooNameSpace@@AAE@J@Z)<br />
<br />
fatal error LNK1120: 1 unresolved externals<br />

adapter.cpp

<br />
#include "adapter.h"<br />
#include "foo.h"<br />
<br />
using namespace FooNameSpace;<br />
<br />
void compute(void)<br />
{<br />
	Goo g;<br />
	g.computeFoo();<br />
}<br />

adapter.h

<br />
#ifdef __cplusplus<br />
extern "C" {<br />
#endif<br />
<br />
void compute (void);<br />
<br />
#ifdef __cplusplus<br />
}<br />
#endif<br />

foo.cpp

<br />
#include "foo.h"<br />
<br />
using namespace FooNameSpace;<br />
<br />
Foo Foo::operator=(long value)<br />
{<br />
  this -> value = value;<br />
  return (*this);<br />
}<br />

foo.h

<br />
namespace FooNameSpace<br />
{<br />
	class Foo<br />
	{<br />
<br />
	private:<br />
		long value;<br />
  <br />
		 Foo (long value) { (*this) = value; }<br />
		 inline Foo operator= (long value);<br />
		 friend class Goo;<br />
  };<br />
<br />
	class Goo<br />
	{<br />
	public:<br />
		void computeFoo()<br />
		{<br />
			Foo foo = Foo(0L);<br />
		}<br />
  };<br />
}<br />

goo.c (link with foo.lib)

<br />
#include "adapter.h"<br />
#include "windows.h"<br />
<br />
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,<br />
                    LPWSTR lpCmdLine, int nCmdShow)<br />
{<br />
	compute();<br />
	return 0;<br />
}<br />

thanks in advance,
George

Viorel.2-Jul-06 21:40

Re: strange linking error with operator overloading

2-Jul-06 21:40

I think no error will be generated if you:

remove the inline keyword from the declaration of Foo::operator =;
or, move the implementation of Foo::operator = from foo.cpp to foo.h file;
or, place the implementation of Foo::operator = function inside the Foo class.

I hope it helps.

George_George2-Jul-06 21:47

Re: strange linking error with operator overloading

2-Jul-06 21:47

Hi Viorel!

Your method is so magic and it works! What is the reason of my linking error and why your method works?

regards,
George

Viorel.2-Jul-06 22:02

Re: strange linking error with operator overloading

2-Jul-06 22:02

As I know, when we work with inline functions, then the body of such items must be provided in .h files, not in .cpp ones. This is because the compiler needs the source code of such functions in order to insert them into compiled code, thus making them "inline".

If we implement a function in a .cpp file, then the compiler makes a binary .obj or .lib file, and the source code is lost. Therefore the compiler will be only able to generate a call to such functions, but not make them inline.

This is also true for template classes and template functions -- they must be delivered in header files. (For instance see STL).

However, it seems that future compilers will allow implementation of inline and template items in .cpp files.

George_George2-Jul-06 23:37

Re: strange linking error with operator overloading

2-Jul-06 23:37

Thank you Viorel!

Viorel. wrote:
As I know, when we work with inline functions, then the body of such items must be provided in .h files, not in .cpp ones. This is because the compiler needs the source code of such functions in order to insert them into compiled code, thus making them "inline".

It should be the linker not the compiler to insert implementations into compiled code, right?

Viorel. wrote:
If we implement a function in a .cpp file, then the compiler makes a binary .obj or .lib file, and the source code is lost. Therefore the compiler will be only able to generate a call to such functions, but not make them inline.

Do you mean we need to insert the source codes of inline function into the modules which invoke inline functions?

I think ordinary function (non-inline function) does not need to insert source codes into the modules which invokes the ordinary function, right? And what did the linker/compiler do when dealing with ordinary function in the same situation?

regards,
George

Viorel.3-Jul-06 0:08

Re: strange linking error with operator overloading [modified]

3-Jul-06 0:08

In my vision, when we call an inline function from 100 different places, the body of function is inserted in each such a place, and then the entire code is compiled. Only compiler can do this task. That’s why we need to supply the source code of inline function to the compiler.

The linker cannot do such task. Linker only assembles compiled code (.obj and .lib files).

In case of non-inline functions, they are compiled once into an .obj or .lib file. In the modules, to the compiler we need to supply only the declaration of such functions. If we call such function from 100 different places, then the compiler will generate a CALL microprocessor instruction in each place, but without an address. The address will be inserted later by the linker.

That’s my opinion.

George_George3-Jul-06 0:33