LUFA and C++

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

anyone with experience on using LUFA in a C++ environment?
I attempted to do so, but did not succeed.

Options -std=c99 or -std=gnu99 are only valid with C, so when I add the flag -x c++ to use C++, the compiler gives a warning, then fails on ConfigDescriptor.h (duplicate const on a declaration)

Although there is something I'm missing, it seems I have to manually change LUFA source code to use C++, and I don't want to do so.

Any ideas?
Tks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

then fails on ConfigDescriptor.h

You realise that to use C headers in a C++ file you need to use?:

extern "C" {
 #include "ConfigDesciptor.h"
}

The actual link against the separately compiled lufa*.c files should just work as there will be no name mangling of the interface to those routines then listed in that extern "C" .h file.

Cliff

(who's starting to learn more about this than is probably healthy. In general I've actually been using:

#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
starting to learn more about this than is probably healthy
Definitely :) And, Yes, that's the way to do it ;)

Did you miss an 'r' out of Descriptor?

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Did you miss an 'r' out of Descriptor?

I imagine the C compiler would have told me ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the replies.
Yes, I realise it! Or better, I realised it, because I'm already working with C++ :-)
The problem is different. Indeed each LUFA header already contains

/* Enable C linkage for C++ Compilers: */
#if defined(__cplusplus)
extern "C" {
#endif

I have a specific problem with this declaration:

uint8_t USB_GetNextDescriptorComp(uint16_t* const BytesRem,void** const CurrConfigLoc,const ConfigComparatorPtr_t const ComparatorRoutine);

The compiler dislikes the double const in the last parameter, unless I set -std=c99 and remove -x c++
And in this case... adieu C++

I could amend the situation by changing the LUFA source code, but I prefer not to mess with it - at least at the moment

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I imagine the C compiler would have told me
Not if you just 'typed' it in as I do ;)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The compiler dislikes
Shame there is no 'Boost' library for the Avr ;)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kalbun wrote:
when I add the flag -x c++ to use C++
Just to be clear, you'll want to compile the LUFA files a C files and compile your own code as C++. With the extern "C" in the LUFA include files all of your linkages with the LUFA functions will be C convention.

So, take the -x c++ out of the compiler command line and the compiler will compile .c files as C and .cpp files as C++.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems your are right, Don.

This works with the final (non beta) version of AVR studio 5. With the beta versions, using .cpp or .cc as C++ extension did not work. There are some messages on the AVR5 forums about this issue.

So far I had to use .c for all files and add -x c++ - and also add definitions of guard_acquire, guard_abort and so on.
Now this is no longer needed but I wasn't aware of this.
So, thank you for pointing me in this direction

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was too eager to reach a conclusion.
No, there is still something that does not work.
Although it seems you can compile a C++ project by simply naming .cc or .cpp your sources, there are still some issues with LUFA.
Ok, this is a new project and I can still choose plain C to do it. Meanwhile I'll ask LUFA author for support.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kalbun wrote:
This works with the final (non beta) version of AVR studio 5.
Unless you enjoy being a pioneer (whom, it is said, one can easily identify by the arrows in their backs) I'd suggest you stick with WinAVR_20100110.

At a minimum, you should have both versions installed and configure your makefile to easily switch between them. That way, if you run into an anomaly with AS5 you can quickly switch to the previous version and see if it exhibits the same problem.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Given that LUFA relies on Makefile building anyway I'd build at the command line with "make" and a LUFA Makefile modified to add your .cpp files to the CPPSRC= line.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dkinzer wrote:
Unless you enjoy being a pioneer (whom, it is said, one can easily identify by the arrows in their backs)

Ahhhh.... now I understand why people ask me so often "what are you doing with those arrows in the back??" :D

I don't enjoy being a pioneer anymore, but bad habits are hard to lose.
Anyway, I routed my C++ related question to Dean (alias abcminiuser), the library author. If I get an answer, I'll publish it here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Giuseppe,

Thanks for the heads-up email - it's probably more useful to have the discussion here so that others can contribute too.

I just tried using LUFA in a C++ project using the latest AVRStudio 5 final release, and it failed miserably, but not for the reasons I expected.

Here's the build string executed by AS5 for a C file:

avr-gcc.exe -funsigned-char -funsigned-bitfields -DBOARD=BOARD_USBKEY -DARCH=ARCH_AVR8 -DF_CPU=8000000 -DF_USB=8000000 -DUSE_FLASH_DESCRIPTORS -Os -ffunction-sections -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99  -mmcu=at90usb1287   -MD -MP -MF"LUFA/Drivers/Board/Temperature.d" -MT"LUFA/Drivers/Board/Temperature.d" -o"LUFA/Drivers/Board/Temperature.o" "../LUFA/Drivers/Board/Temperature.c"

And here's what it's doing with my CPP file:

avr-g++.exe   -MD -MP -MF"LUFATest.d" -MT"LUFATest.d" -o"LUFATest.o" ".././LUFATest.cpp"

Which is no good - the device MMCU option is missing for one, and so is all my defined compile tokens (-D flags). There also isn't a way to supply C++ open compile options in the project configuration dialogue.

That means that C++ is effectively gimped in AS5 for now, and unusable for anything requiring any AVR platform support. The LUFA headers should properly detect C++ usage and add in the needed "extern" stuff automatically, although I haven't really tested this before now. Once AS5 starts behaving properly, I'll be able to see if there are any lingering issues I need to fix for C++ interoperability.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the answer Dean!

Some days ago Atmel released a beta C++ plugin for AS5.
(So I can run my beta code with a beta plugin inside a beta environment :shock: )
It can be installed from tools->extension manager.
Basically it adds a special section for C++ in the toolchain configuration, like in the old AVR32 studio.

I will take another arrow in my back and see what happens with the plugin.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mfile invokes avr-gcc for both but with -x C++ on the .cpp files. Wonder if anyone involved in AS5 has ever looked at mfile?

(sadly I think I already know the answer)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are some results after installing the plugin.
I created an ATmega16U4 C++ project setting USB as a virtual serial, then added LUFA to the right place. Note that I am not using external makefile. I moved everything into the AS5 project file - and this works fine with plain C.

I get a duplicate const error in ConfigDescriptor.c at function definition:

uint8_t USB_GetNextDescriptorComp(uint16_t* const BytesRem,
  void** const CurrConfigLoc,
  const ConfigComparatorPtr_t const ComparatorRoutine);

To compile it I have to remove one of the two "const", but I am not that sure this was a good move.
Another compiler error is removed by putting the extern "C" stuff to Drivers\USB\Core\device.h
But at the end I get the compile error:

'undefined reference to `CALLBACK_USB_GetDescriptor'

although the function is defined, and there shouldn't be any problem with C/C++ calling convention.
So I am stuck, but I suppose someone with better C/C++ knowledge than me could solve the issue

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just had a poke around with this myself.

Quote:

To compile it I have to remove one of the two "const", but I am not that sure this was a good move.

That's now fixed in the latest SVN/GIT - I just removed the first const, since the important bit is that the pointer itself cannot be altered inside the function, rather than the data being pointed to.

Quote:

Another compiler error is removed by putting the extern "C" stuff to Drivers\USB\Core\device.h
But at the end I get the compile error:

That should also be fixed now in the repository - I missed a few C linkage macros in some of the header files.

Grab the latest repository revision as an archive here:
http://www.lufa-lib.org/latest-a...

Cheers!
- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great!
I confirm that, with the latest SVN archive, LUFA can be compiled inside a C++ project with no changes to Dean's source code.
8)
I also tested it on our 16U4 board and everything seems to work fine, at least with CDC

A very good result for me, becase our project is still at an early stage so we can easily switch from C to C++
Thanks for the support :-D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
easily switch from C to C++
:) Yeah, right! :twisted:

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I confirm that, with the latest SVN archive, LUFA can be compiled inside a C++ project with no changes to Dean's source code.

Excellent! Let me know if you encounter any more issues, since (as far as I know) you're the first to actually try to mix C and C++ in a LUFA application.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been looking at LUFA, trying to integrate it with an existing project. It is a nightmare, the custom makefile is a real pain in the arse. I was expecting it to be nice and clean like V-USB, but the whole code-base is horrible. A rat's nest of files and masses of code needed for even the simplest demo.

No offence Dean, but I really think you should take a look at V-USB and consider how people are going to use the code in their application. Doing any config in a makefile is a really, really bad idea. For example it can break IDE, so when you double click on an error in the build log window in AVR Studio 4 it just ignores you. You have to manually edit it to add each source file or change a path.

The makefile is there to build the software, and isn't even a particularly good way of doing that which is why many IDEs don't use them. Configuration should be in header files.

In the end I gave up and am trying to decide between the Atmel stack and the Teensy ultra-minimal one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Excellent! Let me know if you encounter any more issues, since (as far as I know) you're the first to actually try to mix C and C++ in a LUFA application.

- Dean :twisted:


Do we get partial credit for trying and failing. :) I'll try again later.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregsmithcts wrote:
Quote:
easily switch from C to C++
:) Yeah, right! :twisted:

If it's about switching compiler (not actually adopting another programming paradigm), then not a very big deal..

Once you've started utilizing C++ constructs, going the other way will definitively be harder.. :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregsmithcts wrote:
Quote:
easily switch from C to C++
:) Yeah, right! :twisted:

I recently switched all the files in a project from C to C++. It involved changing the file extensions from .c to .cpp and adding some extern "C" guarding on header file inclusions for libs written in C.

(the reason was simply so the code could now instantiate some C++ classes and use their methods but the actual conversion was trivial).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I recently switched all the files in a project from C to C++.
As has already been noted, C++ is a superset of C. Therefore, (almost) anything you can do in C can be compiled as is, in C++. That was not my point however, as I guess you well know by now.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregsmithcts wrote:
That was not my point however, as I guess you well know by now.

Oh what? :shock: Taken out of context? :wink:

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The makefile is there to build the software, and isn't even a particularly good way of doing that which is why many IDEs don't use them. Configuration should be in header files.

The only "special configuration" going on is a few definitions, and easier source file requirement detection. If you wish, you're free to add the required module source files (see the documentation on each module) to your project manually, and add the required configuration defines (ARCH, F_USB, etc.) to your IDE's project settings.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the end I just modified the Teensy example code to add a bulk transfer interface.

I can't recommend taking a look at V-USB highly enough. It is simple to use and integrate into an existing or new project, compact and tidy. Yet when you need advanced features they are all available for easy access. Despite doing the USB interface itself in assembler via bit banging with hand-tuned code for different oscillator speeds it still manages to keep the number of source files down and automatically select all the right settings from the standard AVR Studio makefile.

As an example my Retro Adapter uses multiple USB and HID descriptors with switching on-the-fly, without the code quality or readability suffering.

I tried out Atmel's stack but it isn't organised very well. The random and deep directory structure doesn't help either.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It compiles, i can use normal c code but i cannot use a class in the header.

Details, please.

Build error? Verbatim quote of message, please.

Perhaps show the code where you "cannot use a class in the header"?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gawd, I hate pastebin.. (Why not simply paste the code'n'stuff here, sutrround it with CODE tags and be done with it?

but now its clean. Extern C also doenst help.

Is the stuff in the dreaded pastebin building clean or not? If not, then again: What errors? (paste here, NOT in pastebin)

Quote:
i cannot define the functions in the .cpp

This says nothing about the problem. If you've cut your hands off with a chain-saw then that explains why you can not press the appropriate keys on the keyboard :wink:. But if you get a build error the PLEASE quote it verbatim here. There is no chance at all that we can guess correctly what error you get.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The error is still

And the code that generates that?

No, I won't go to Pastebin for it. Post it here. What happens else is that X months from now someone has a problem similar to yours, finds this thread and only ses half of the facts since the Pastebin parts have been eradicated.

Forums are just as much about saving experiences for furure readers as solving your problem now.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This has nothing to do with C++ v/s C.

Your include guard is broken. Include guards starts with an #ifndef (not an #ifdef).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But now i get the error i had before:


That's C++ code being passed to the C compiler.

If the avr-gcc compiler driver is used then .cpp should automatically be passed to avr-g++ but it looks like that may not be happening.

Or are you saying that Testx.h was being #include'd from a .c file when that error was generated? Obviously any .h that is to be shared between C and C++ not only needs extern "C" when it's seen in the C guise but all the C++ specific stuff must also be hidden.

To avoid confusion it may help to use .hpp not .h for C++ specific headers. If you find yourself including a .hpp in a .c file you know you may be in for a rough ride!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tell us what file is compiled when you get those messages.

I suspect it is not Testx.cpp but a .c file.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sure I've thought about writing the tutorial on this a hundred times. The round tuit was never acquired, though..

So, here's the short version with no detailed background explanation:

How to call C code from C++
Make sure C++ code sees the function prototype "decorated" with

extern "C"

and call the function from C++.

How to call C++ code from C
You can not call C++ code from a .c source file. What you do is create a "proxy" function with C linkage, i.e. "decorated" with

extern "C"

in a .cpp file. This proxy can call C++ code in this or other .cpp files, and it in turn can be called from C code in a .c source file.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Yeah i wanted to call a cpp file from a c file. I didnt know that this is impossible.

It isn't, and I didn't say that. I am astonished you read that into my post.

I said, "you can not call C++ code from a C file". I also think I was explicit in saying that you can have a extern "C" function in a C++ file, and that this funtion then can be called from C, and that this funtion can in turn contain C++ code and do calls to C++ functions (freestanding or members of a class).

Being really nitpicking you never call a file from another file. Not in C. Not in C++. But I realize that that was just sloppy language. :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan,

This often confuses me but if you have a C++ class and want to call a member function from C then, because the C won't be providing "this" is it not the case that the extern C function has to be static? Or how do you avoid the issue of "this"? Clearly you cannot instantiate an object of the class from within the C that's going to try and call the exposed function.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Clearly you cannot instantiate an object of the class from within the C that's going to try and call the exposed function.

From a C file? No.

Fron an extern "C" function in a C++ file? Oh yes, you can!

Again: You place a function in a C++ file. It has C calling conventions (because you put extern "C" on it) but it can contain C++ code, including instantiating objects, calling non-static member functions (which will pass the this-pointer) etc.

The extern "C" governs the calling/linkage information for the function. Nothing else.

I threw together a very small example. I have tested this in MS Visual C++:

1) The class, and a pointer to point to an instance, is (of-course) in a CPP file.

2) In that file there are also two "proxy functions". By using extern "C" they get C linkage. But they are in a CPP file and may contain C++ code.

// callee.cpp

class Callee
{
public:
   Callee(int i) : _i(i)
   {}

   int foo()
   {
      return _i;
   }

private:
   int _i;
};

// Pointer to an instance
Callee * pCallee;


// The proxies. These are C++ functions (in that they can contain C++ code) but with C linkage.

extern "C" 
void calleeConstruct(int i)
{
   // Using the new operator!
   pCallee = new Callee(i);
}

extern "C"
int calleeFoo(void)
{
   // Calling a member function!
   return pCallee->foo();
}

3) A header file for the proxy functions. I actually haven't tested the "C++ guards" - I just threw them in because otherwise you would have been nitpickin' re that. :wink:

// callee.h

#ifdef CPLUSPLUS
extern "C" {
#endif

void calleeConstruct(int i);
int calleeFoo(void);

#ifdef CPLUSPLUS
}
#endif

4) Now, from a C file we can call the proxies

// caller.c

#include "callee.h"

void caller(void)
{
   int i;
   calleeConstruct(42);
   i = calleeFoo();
}

Everything clear now?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Everything clear now?

Crystal :-)