• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 372 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Migration of functionality from C to C++

Andrew Eldredge
Intellectual 320 points

I am attempting to leverage c++ in an area of my code that has been written in C and includes other C headers.  While moving a variable, in this case a static global to a class member, I had to included the C header which defined the structure.  It is at that point that I started running into compiler problems withe headers which I presume are down the include chain.  Some of these errors were repeated several times.

"C:/ti/ccsv5/tools/compiler/tms470/include/stdio.h", line 317: error: expected an identifier
"C:/ti/ccsv5/tools/compiler/tms470/include/stdio.h", line 317: error: expected a ";"

"C:/ti/ccsv5/tools/compiler/tms470/include/string.h", line 305: error: expected an identifier
"C:/ti/ccsv5/tools/compiler/tms470/include/string.h", line 305: error: expected a ";"

"C:/ti/ccsv5/tools/compiler/tms470/include/stddef.h", line 75: error: expected an identifier
"C:/ti/ccsv5/tools/compiler/tms470/include/stddef.h", line 75: error: expected a ";"

In each of these cases, the errors occured within a section beginning with:

#if defined(__cplusplus) && !defined(_CPP_STYLE_HEADER)

This project has grown to the point that it is difficult to map out the include dependencies.  It appears the compiler is making several passes at these headers.  Is it possible that one pass without the c++ symbols could be corrupting the state of the compiler for subsequent passes? 

  • 0
    TI__Guru* 84285 points

    What version of the TMS470 compiler are you using?

  • 0 in reply to Archaeologist
    Intellectual 320 points

    Project Properties -> CCS General -> Compiler Version tells me 4.9.0, but another peilf tells me that the effective version is 4.9.1. 

    A Diagnostic option lets me output the version it in the build output, which agrees with version 4.9.1.

    I see that there is a 4.9.2 version available.  Should that help?

  • 0 in reply to Andrew Eldredge
    TI__Guru* 84285 points

    Each of those lines looks exactly the same:

    using std::size_t;

    The error message you are getting leads me to believe that somewhere in one of the header files you are including, someone has defined size_t to be a macro, most likely "unsigned int".  This is not done anywhere in the compiler's header files, so the culprit is somewhere else.  Upgrading the compiler is not going to help.  You'll need to find the offending definition and replace it with '#include <stddef.h>"

  • 0 in reply to Archaeologist
    TI__Guru**** 249680 points

    A suggestion on how to find the problem size_t line ... Preprocess the file as described here.  But don't submit the resulting preprocessed file to us.  Instead, search it for size_t.  That should lead you to the problem.

    Thanks and regards,

    -George

  • 0 in reply to Archaeologist
    Intellectual 320 points

    CCS tells me about the following definitions of size_t:

    C:\StellarisWare/third_party/ptpd-1rc1/src/dep-lmi/ptpd_dep.h

    #ifndef size_t 
    #define size_t long
    #endif

    C:\ti\ccsv5\tools\compiler\tms470\include\string.h

    C:\ti\ccsv5\tools\compiler\tms470\include\stddef.h

    C:\ti\ccsv5\tools\compiler\tms470\include\stdio.h

    C:\ti\ccsv5\tools\compiler\tms470\include\time.h

    #ifndef _SIZE_T
    #define _SIZE_T
    typedef __SIZE_T_TYPE__ size_t;
    #endif

    The only one that does not match is the ptpd_dep.h, which is interesting because it is in the dependancies of ptpdlib.h, the inclusion of which is what exposed this problem in the first place.  I've changed it to have the same type of protection using a typedef and the _SIZE_T symbol definition.  The initial results seem to be promising.  Do we count this as a defect with the vendor of the ptpd code?

  • 0 in reply to Andrew Eldredge
    TI__Guru* 84285 points

    Andrew Eldredge said:
    Do we count this as a defect with the vendor of the ptpd code?

    Yes.