.c vs .cpp file

[metdos]

This is the situation, I wonder the reason.

in .c file this works properly

vciDeviceOpen(&sInfo.VciObjectId, &hDevice);

and this gives error :error C2440: 'function' : cannot convert from 'VCIID' to 'REFVCIID'

vciDeviceOpen(sInfo.VciObjectId, &hDevice);

but in .cpp file this works properly

vciDeviceOpen(sInfo.VciObjectId, &hDevice);

and this gives error :error C2664: 'vciDeviceOpen' : cannot convert parameter 1 from 'VCIID *' to 'REFVCIID'

vciDeviceOpen(&sInfo.VciObjectId, &hDevice);

[m22]

the 'C' code is passing a pointer to the value in the first call, and the actual value in the second call. (In the first case, you can actually change the value in the function.)

the 'C++' code I am imagining that the function declaration says that the first parameter is a 'reference' parameter (not a pointer to). The c++ compiler can automatically (and quietly) pass a reference to something from the caller side. When you put the '&' on the call to the function, you are saying 'pass a pointer, not a reference'. well a pointer and a reference are not the same and there is no non-explicit conversion between the two.

[Salem]

> .c vs .cpp file
If you're already making statements like "this works in C and not C++", then you really need to take a big step back and look at what it is you're trying to learn.

Some half-assed c/c++ hybrid (what you're going to end up with) isn't going to do you or anyone else any good in the long run.

C is traffic moving in one direction.
C++ is traffic moving in the other direction.
C/C++ is walking the median line, waiting to be road-kill.

[m22]

> .c vs .cpp file
If you're already making statements like "this works in C and not C++", then you really need to take a big step back and look at what it is you're trying to learn.

Some half-assed c/c++ hybrid (what you're going to end up with) isn't going to do you or anyone else any good in the long run.

C is traffic moving in one direction.
C++ is traffic moving in the other direction.
C/C++ is walking the median line, waiting to be road-kill.

well, there's that too...:-)

quick! what's the result of

int C = 1;

double a = C/C++;

sorry, couldn't help myself...:-)

[m22]

and then I thought about it a minute...
I *hate* seeing code like this.
kind of like "Look what I can do!"
"What?"
"Well, Look!"
"What's it mean?"
"Well,..."

if it takes
1) you longer than a second to get an answer
2) you come up with more that one answer
3) if the answer is 'it depends'
4) you don't know
5) you don't know there is a problem
6) someone smacks you in the back of the head when you ask them what the answer is;

You're doing it wrong.

The only thing *for sure* is that at the final ';',
C will equal 2.

a good optimizing compiler could even statically initialize the variables and not even generate any executable code.

proof left to the reader...