Hi,
Is it possible/recommended to have a driver project that has both C and C++
source files? I have added a C+ file to my driver project which compiles OK
but generates a linker error which I half expected it to do because of
differences in the way function names are created for the two file types.
How would a function in a C++ fule be coded that will allow it to be called
from a C file?
Regards FarmerJo
extern “C” MyCallable FromCFunction(firstargtype first arg, …) will do the job for you.
You can use as this example:
//C1.cpp
extern “c” void fun();
void fun()
{
//TODO
}
//c2.c
int main()
{
fun();
return 0;
}
[ntdev] Mixing C and C++ files in a driver project.
Hi,
Is it possible/recommended to have a driver project that has both C and C++
source files? I have added a C+ file to my driver project which compiles OK
but generates a linker error which I half expected it to do because of
differences in the way function names are created for the two file types.
How would a function in a C++ fule be coded that will allow it to be called
from a C file?
Regards FarmerJo
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I did try putting extern “C” in front of the function definition which works
fine but the problem occurs when I try to call it from a C module. I have
the following three modules.
temp.cpp
extern “C” void temp(void)
{
…
}
temp.h
extern “C” void temp(void); … (1)
init.c
#include “temp.h”
void SomeFunction(void)
{
temp();
}
In this case I get a two errors as follows.
… error C2059: syntax error: ‘string’
… error C4013: ‘temp’ undefined; assuming extern return int
The first error refers to the line shown in (1) above. Is this the correct
syntax for the declaration? The second occurs because temp.obj was not
correctly compiled due to the first error.
Regards FarmerJo
you should change to like this,
temp.h
void temp(void);
/////////////////////////////////////////
I did try putting extern “C” in front of the function definition which works
fine but the problem occurs when I try to call it from a C module. I have
the following three modules.
temp.cpp
extern “C” void temp(void)
{
…
}
temp.h
extern “C” void temp(void); … (1)
init.c
#include “temp.h”
void SomeFunction(void)
{
temp();
}
In this case I get a two errors as follows.
… error C2059: syntax error: ‘string’
… error C4013: ‘temp’ undefined; assuming extern return int
The first error refers to the line shown in (1) above. Is this the correct
syntax for the declaration? The second occurs because temp.obj was not
correctly compiled due to the first error.
Regards FarmerJo
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thought I might need to add that when I posted originally:
In temp.h:
#if defined(__cplusplus)
Extern “C”
#endif
Temp(void);
The constant name is described in the compiler documentation- compiler defines it when a C++ file is being processed, so you can use a header for both languages.
#if defined(__cplusplus)
Extern “C”
#endif
This method is always used in C style head file, because when you had wrote
some c style codes, and these functions will be called in C++ files. You
should add this snippet in your c style head file. Because when the C++
files be compiling, the C++ compiler will working and the __cplusplus will
be defined.
But when you call a C++ function in a C file ,the working compiler is a C
compiler, so the __cplusplus will not be defined. So the extern “C” will not
be used in your temp.h file.
now I tell you some rules,
When you want to call C functions in C++ files, you can used as follow:
//1.c
Void fun1()
{
…
}
Void fun2()
{
…
}
//1.h
#pragma once
#ifdef __cplusplus
extern “C”{
#endif
Void fun1();
Void fun2();
#ifdef __cplusplus
}
#endif
//2.cpp
#include 1.h
void Testfun()
{
Fun1();
}
When you want to call C++ functions in C file, you can as follows:
//1.cpp
extern "C"Void fun1()
{
…
}
extern “C” void fun2()
{
…
}
//You alse can use this way
Extern “C”{
Void fun1()
{
…
}
Void fun2()
{
…
}
}
//1.h
#pragma once
Void fun1();
Void fun2();
//2.c
#Include “1.h”
Void Testfun()
{
fun1();
fun2();
}
/////////////////////////////////////
RE: Re:[ntdev] Mixing C and C++ files in a driver project.
Thought I might need to add that when I posted originally:
In temp.h:
#if defined(__cplusplus)
Extern “C”
#endif
Temp(void);
The constant name is described in the compiler documentation- compiler
defines it when a C++ file is being processed, so you can use a header for
both languages.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Change all source file extensions to .CPP and you never have to worry about this. The other benefit is you are free to use C++ extensions in header files. I think it is good practice to name all files .CPP, even if you do not intend to use anything up and above C.
At 04:32 26/04/2008, xxxxx@gmail.com wrote:
Change all source file extensions to .CPP and you never have to
worry about this. The other benefit is you are free to use C++
extensions in header files. I think it is good practice to name all
files .CPP, even if you do not intend to use anything up and above C.
Oh bugger !!! May the person who uses this troll bait to
resurrect the C vs C++ debate be eternally condemned to run Vista.
No Mark banish him to Linux, there is stupid and this is beyond it.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Mark S. Edwards” wrote in message
news:xxxxx@ntdev…
> At 04:32 26/04/2008, xxxxx@gmail.com wrote:
>>Change all source file extensions to .CPP and you never have to worry
>>about this. The other benefit is you are free to use C++ extensions in
>>header files. I think it is good practice to name all files .CPP, even if
>>you do not intend to use anything up and above C.
>
>
> Oh bugger !!! May the person who uses this troll bait to resurrect
> the C vs C++ debate be eternally condemned to run Vista.
>
>
>
To Don,
No Mark banish him to Linux,
I just wonder how Linux may be related to it…
After all, Linux drivers are written in C - writing drivers in C++(and, apparently, in not-so-distant future in C#), as well as relying upon various frameworks, is 100% MSFT-specific feature, so please keep Linux out of it…
To Mark,
May the person who uses this troll bait to resurrect the C vs C++ debate be eternally
condemned to run Vista.
I would go further than that - I would rather condemn him to eternally write drivers for MSFT systems of any description and eternally discuss issues like “writing drivers under the framework A in managed language X vs writing drivers under the framework B in scripting language Y”…
Anton Bassov
Don Burn wrote:
No Mark banish him to Linux, there is stupid and this is beyond it.
Pardon me, just got home and I’m a little ‘tanked’… I do disagree with
the original statement, but
I seem to recall that to use the ‘/w4’ switch, the file extensions had
to be cpp.
Then again, I seem to recall adding '/w4 'to the ‘sources’ file with
projects that included only “c”
files.
/w4 can be used without the .cpp extension right?
Matt
/w4 has always been useable without .cpp and in fact most of the arguments
for using .cpp as an extension to “get a better C” go away if one uses /W4.
Beyond /W4 is /Wall unfortunately the Microsoft includes choke on this so
you have a lot of work to use /Wall. Beyond either of those you can do
extra work to turn back on many of the warnings that the WDK environment
turn off by use of warnings.h.
I filed bug reports for years to get /W4, of course about the time they do
it, the compiler started supporting /Wall. And as the Microsoft folks told
me when /W4 support was first released, “It is a hack, and we should go back
and do it right at some point”, unfortunately those folks have moved on from
the WDK.
So a wise developer uses /W4 /WX where the second switch indicates that if
there are warnings treat them as errors and don’t create an object file.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Matt” wrote in message news:xxxxx@ntdev…
> Don Burn wrote:
>> No Mark banish him to Linux, there is stupid and this is beyond it.
>>
>>
>>
> Pardon me, just got home and I’m a little ‘tanked’… I do disagree with
> the original statement, but
> I seem to recall that to use the ‘/w4’ switch, the file extensions had to
> be cpp.
>
> Then again, I seem to recall adding '/w4 'to the ‘sources’ file with
> projects that included only “c”
> files.
>
> /w4 can be used without the .cpp extension right?
>
> Matt
>
>
>
>
>
No idiots like this need to be driver from the Windows driver development
environment, since all they do is hurt the system and those of us who are
professional enough to do it right.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> To Don,
>
>
>> No Mark banish him to Linux,
>
>
> I just wonder how Linux may be related to it…
>
> After all, Linux drivers are written in C - writing drivers in C++(and,
> apparently, in not-so-distant future in C#), as well as relying upon
> various frameworks, is 100% MSFT-specific feature, so please keep Linux
> out of it…
>
>
> To Mark,
>
> > May the person who uses this troll bait to resurrect the C vs C++ debate
> > be eternally
>> condemned to run Vista.
>
> I would go further than that - I would rather condemn him to eternally
> write drivers for MSFT systems of any description and eternally discuss
> issues like “writing drivers under the framework A in managed language X
> vs writing drivers under the framework B in scripting language
> Y”…
>
>
> Anton Bassov
>
>
>
>
Don,
No idiots like this need to be driver from the Windows driver development environment,
I don’t want to start yet another “flame war”, but somehow it happens that MSFT does everything it can possibly do to make it possible for idiots like that ( and far worse than that) to write Windows drivers, no matter how limited their technical knowledge is. OK, KMDF will handle PnP and PM for an idiot, but what are they going to do when he/she decides to wait at elevated IRQL or starts looking for a way to handle interrupts in the user mode???
…since all they do is hurt the system and those of us who are professional enough to do it right
Do you really think it is a good idea to provide them with frameworks and other helpers - if they have no helpers, there is a good chance that they would just fail to run their crap without a BSOD even on single occasion, so that it would never reach the production stage, in the first place. OTOH, if MSFT does not provide them with helpers, someone else would (Jungo, late DriverStudio, etc). …
Anton Bassov
I agree with this, it’s been standard practice here at OSR for many years, and strongly recommend it to our students and anybody who hasn’t tried it. Not only to you get strong typing, but you can be sloppy with your variable declarations and put them anywhere in your program. OK, OK, that last one was just a joke…
Personally, I’ve found that while /W4 can sometimes be helpful, it usually generates too much noise for me.
I vote for .CPP with ordinary C language (well, not counting comments),
Peter
OSR
Personally, I find there are few spurious warning with /W4, it is actually
amazing the number of times I have found real bugs in Microsoft and others
samples by using /W4, including years ago a construct like:
ULONG x;
if ( x < 0 )
{
}
that was in an OSR sample from an expensive toolkit. I also remember years
ago people grumbling since I made them use /W4 when I was the architect of a
project, then I went out to Redmond for a special class where I got a first
look at PreFast and a couple of large drivers came up with only 1 prefast
error between them, the instructor a guy named Peter 
commented that we
were careful in writing our code. Of course the folks in the next station
only were struggling with several thousand prefast problems in a widely used
driver.
The other thing about /W4 and all the other static tools are if take the
time to look at the code while fixing the apparent “false positives” many
times you find things you question or could do better.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
>
>
> I agree with this, it’s been standard practice here at OSR for many years,
> and strongly recommend it to our students and anybody who hasn’t tried it.
> Not only to you get strong typing, but you can be sloppy with your
> variable declarations and put them anywhere in your program. OK, OK, that
> last one was just a joke…
>
> Personally, I’ve found that while /W4 can sometimes be helpful, it usually
> generates too much noise for me.
>
> I vote for .CPP with ordinary C language (well, not counting comments),
>
> Peter
> OSR
>
>
FLAME ON
Sorry Anton but you have in my opinion moved firmly into the IDIOT CATEGORY.
Doing PnP right was a pain in the ass, amd most of the samples (and things
like DriverStudio) did not get it right. KMDF is as much for the
professional as it is for the newbie. No one would be bitching about KMDF
if Microsoft had released it first, but now many people blame it, or
complain “where is the source”. Yes, the source could be nice, but then
idiots would confuse implementation with architecture like they do in the
open source world.
Personally I have never found a single bug by using .cpp, but I have found
serious bugs by removing .cpp and building the driver with /W4. Idiots who
keep pushing C++ for all driver developers (yes I know some pro’s who use it
well more power to them) including newbies who don’t know the trouble they
can get it are as STUPID who are the solution to everything is HOOKING"
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Don,
>
>>No idiots like this need to be driver from the Windows driver development
>>environment,
>
> I don’t want to start yet another “flame war”, but somehow it happens that
> MSFT does everything it can possibly do to make it possible for idiots
> like that ( and far worse than that) to write Windows drivers, no matter
> how limited their technical knowledge is. OK, KMDF will handle PnP and PM
> for an idiot, but what are they going to do when he/she decides to wait
> at elevated IRQL or starts looking for a way to handle interrupts in the
> user mode???
>
>>…since all they do is hurt the system and those of us who are
>>professional enough to do it right
>
> Do you really think it is a good idea to provide them with frameworks and
> other helpers - if they have no helpers, there is a good chance that they
> would just fail to run their crap without a BSOD even on single occasion,
> so that it would never reach the production stage, in the first place.
> OTOH, if MSFT does not provide them with helpers, someone else would
> (Jungo, late DriverStudio, etc). …
>
> Anton Bassov
>
Don,
Sorry Anton but you have in my opinion moved firmly into the IDIOT CATEGORY.
To be right honest, taking into consideration all hysterical statements that you made on this thread about Linux, open source, hooking and other topics that are totally unrelated either to each other or to the topic of this discussion, as long as the above statement comes from *YOU*, I take it as a compliment - I would be much more worried if you said that, in your opinion, I am bright…
Anton Bassov
xxxxx@gmail.com wrote:
Change all source file extensions to .CPP and you never have to worry
about this. The other benefit is you are free to use C++ extensions
in header files. I think it is good practice to name all files .CPP,
even if you do not intend to use anything up and above C.
As long as all the source file contents are C++ rather than C, of course
…