ucos ii and c++ compiler

I'm sorry I didn't say that the header file support c++. At the beginning is written the "extern "C"" directive.
On monday I'll post the complete error, I cannot compile now.
thanks a lot
michele

Neither can we. If you get errors, it will be _much_ easier for us to respond if you also take the time to post the full error messages you happen to get.

It might be that the header file doesn't support C++, in which case you may have to write:

extern "C" {
#include <ucos_ii.h>
}

to tell the compiler that all symbols in the header file are using the C naming convention.

C != C++;
They are not the same language. There are difference in syntax. You may have some more issues after you get it to compile.

C != C++;

Maintaining compatibility with C was one of the design goals of C++. See here:
www.dmk.com/.../stroustrup_1986_10.html
Yet, as Neil is rightly pointing out, there are a few subtle differences in semantics which could break working C programs.
By the way, keeping compiles fast was a design goal too. That didn't work out too well, at least with gcc: in my experiance, C++ compiles take several times longer than C compiles for similarly sized programs.

This could be off topic, but what are the advantages of moving an existing C project to C++? I can clearly see disadvantages: C++ is a much more complex language with lots of pitfalls (as if C didn't have enough of those!), C++ requires more training to write programs efficiently, mixing C and C++ in the same project brings another source of confusion for the maintainer. There must be a really good upside to outweigh those.

Regards,
- mike

That is a very good question!

C++ is Object-Oriented - that is likely to mean a different design philosophy from a C project.

So, surely, moving an existing design from a C to a C++ implementation is a bit pointless - you would need to re-design the project in an Object-Oriented fashion to gain a real benefit...?

But on the other hand: C++ was specifically designed to make it easy to slowly, step-by-step, take advantages of new features in the language.

The ability to add a method to an existing struct, or to make use of a reference, or to add a new function with identical name but other set of parameters can be very valuable.

C++ is designed to support object-orientation, but it does not require it. It represents a more complete language, even without the objects.

"But on the other hand: C++ was specifically designed to make it easy to slowly, step-by-step, take advantages of new features in the language."

that is exactly what I would like to do. I cannot redisign completely a project that is working fine and is shared with other developers .. I need to do it slowly.
My idea is to make the first step and switch to the c++ compiler living the project almost as it is and then start designing using objects (we will do also a course about c++ and "objects").
The problem is that just switching to the c++ compiler seems to be not so easy: problems with the ucos II (that should support c++), problems with "bit" declarations, ..

Thank you very much for your posts, tomorrow I'll post the error I got.
Have a nice sunday
Michele

Hi,
I'm back at work. That's the error I get when I compile my main.cpp

compiling main.cpp...
..\Src\.\rtos\ucos_ii.h(752): error: expected an expression
..\Src\.\rtos\ucos_ii.h(752): error: expression must have (pointer-to-) function type
..\Src\.\rtos\ucos_ii.h(752): error: type name is not allowed
..\Src\.\rtos\ucos_ii.h(752): error: identifier "pd" is undefined
..\Src\.\rtos\ucos_ii.h(752): error: expected a ")"

and that is line 752 of ucos_ii.h

INT8U OSTaskCreateExt(void (*task)(void *pd), void *pdata, OS_STK *ptos, INT8U prio, INT16U id, OS_STK *pbos, INT32U stk_size, void *pext, INT16U opt);

As I said before, the header should be c++ compliant.
I tried to comment the first declaration "void (*task)(void *pd)," so it seems there is something wrong in it.
Thanks very much for your help
michele

Thank you very much for your help

I wrote your declaration in my .h file and the compiler passes it fine.

Perhaps the compiler is confused by the pointer-to-function as an argument? You can try and verify this by trying to compile a simplified version of the declaration:

int func(void (*fptr)(void *ptr));

See if the compiler chokes on this. If it does, it will be a bug in the compiler, I think...

I tried to change the function declaration from

OSTaskCreateExt(void (*task)(void *pd), ..

to

OSTaskCreateExt(void (*INT16U)(void *pd), ...

Can it be that "task" is not declared? Doesn't it know what it is? I searched in ucos ii .h files and I cannot find a declaration for "task".

"Can it be that "task" is not declared?"

In a function pointer theclaration:

STaskCreateExt(void (*task)(void *pd), ..

"task" is just an arbitrary name for this parameter, just as:

int sum(int a,int b);

the parameter names a and b are arbitrary names.

It will not be problematic unless "task" is a reserved keyword, or possibly the name of a data type.

that's line 752

#if OS_TASK_CREATE_EXT_EN > 0

I did that
#ifdef __cplusplus
INT8U OSTaskCreateExt(void (*INT16U)(void *pd),
#else
INT8U OSTaskCreateExt(void (*task)(void *pd),
#endif

and it compiles.
I tried the modification in my c project and I downloaded the firmware on my board and it works .. but I don't like to just trick the code without understanding why it works.
Thanks very much for your help

I wrote your declaration in my .h file and the compiler passes it fine

Then it must be something above line 752. Often you get compiler errors on lines following the line which actually causes problems.
The error messages 'expected an expression' and 'expression must have (pointer-to-) function type' might mean that the compiler thinks that it is processing the body of a function.
Perhaps it would be a good idea to post some code preceeding line 752 here.

As I said, changing "task" to INT16U it compiles .. but I still have a linker problem

*** ERROR L127: UNRESOLVED EXTERNAL SYMBOL SYMBOL: _main MODULE: ..\Obj\main.obj (MAIN)
*** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: _main MODULE: ..\Obj\main.obj (MAIN) ADDRESS: A60DH
*** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: _main MODULE: ..\Obj\main.obj (MAIN) ADDRESS: A60EH

Do you have any suggestion? The main is declared in main.cpp as int main(void){ .. }