What causes the error #18 expected a ")" on a MSP430

Question

Compiling the following C++14 code for a MSP430 using TI Code Composer I got the following errors:

subdir_rules.mk:14: recipe for target 'main.obj' failed
"Interface.h", line 75: error #18: expected a ")"
"Derived.h", line 91: error #18: expected a ")"

This is for the following code structure in which the Interface.h class is a library which compiles fine for STM32 targets.

#include <cstdint>

namespace NS
{
  class Interface 
  {
    public:
      // Other pure virtual functions such as:
      virtual void advance() = 0;

      // This is the problem function
      virtual void advance(const uint32_t N) = 0;
  };
}

Next in the MSP430 project the interface is used in multiple objects. This is one example of multiple implementations, they all give the same error.

#include "Interface.h"

class Derived : public ::NS::Interface
{
  public:
    // Overriding virtual functions with implementations in cpp file.
    void advance() override;

    // The problematic function
    void advance(const uint32_t N) override;

  private:
    uint32_t index;
};

The cpp file:

#include "Derived.h"

Derived::advance() 
{
  ++index;
}

Derived::advance(const uint32_t N)
{
  index += N;
}

Now inspecting the code for any "funny" characters like Greek question marks did not yield any result. I tried replacing the text, typing it again etc to no result

Commenting out the functions advance(const uint32_t N) resolves the problem so it is not something else in the file.

What could cause this problem?

Did you `#include ` for `uint32_t`? Please show us a [example], not just excerpts. — the busybee, Sep 12 '21 at 08:15
@thebusybee Good poitn, in the original it is included, added it to the question. — Bart, Sep 12 '21 at 10:42
If you `#include ` (as opposed to `#include `), you should use qualified names like `std::uint32_t` because the C++ standard does not require those to be available in the global namespace, IIRC. — heap underrun, Sep 12 '21 at 12:36
@heapunderrun I understand what you say. What I do not understand is how it is possible that other functions with `uint8_t` in `Interface` do not have the same problem. In `Derived` `uint32_t` is used as a variable without any problems. — Bart, Sep 12 '21 at 14:38
The error messages refer to lines 75 in Interface.h and 91 in Derived.h. Indicate which these line numbers refer to. However the likely culprit is whatever appears prior to those lines to make the compiler expect a closing parenthesis - including errors in any nested includes prior to the error line. — Clifford, Sep 12 '21 at 21:07
@Clifford Those line numbers are the definition and implementation of `advance()`. Should have noted that in the question. — Bart, Sep 13 '21 at 06:52
It is possible that some other previous include (nested or direct) has moved std::uint32_t to the global namespace, but that does not make it correct to omit it. That said, unless you know otherwise, I doubt that is the problem. Capitalisation is conventionally used for macros in C; I would avoid using N as a parameter name. If N is defined as a macro elsewhere, that would certainly invalidate the advance() declaration/definition. — Clifford, Sep 13 '21 at 08:22
@Clifford I will try to use n instead of N. Or better even an longer unique name. — Bart, Sep 13 '21 at 08:34
@CL from the top of my head it is 20.xxx. I've updated Code Composer yesterday. — Bart, Sep 13 '21 at 09:45

score 1 · Accepted Answer · answered Sep 14 '21 at 14:35

1

The problem was indeed as @Clifford mentioned. N was already defined somewhere in the MSP430 code. Renaming Derived::advance(const uint32_t N) to Derived::advance(const uint32_t N_bytes) solves the problem.

answered Sep 14 '21 at 14:35

Bart

1,405
6
32

1

You can and should accept your own answer. When looking at apparently inexplicable errors, you have to remember that the compiler is reporting on the code _after_ preprocessing has been applied - not the source text, so you have to consider the code in that context. Preprocessor Macros are not subject to the same scope rules as C code, and `N` is clearly a poor name for a macro and ill-advised as a variable/parameter name - a perfect storm of ill-advised naming practices has caused this. – Clifford Sep 17 '21 at 12:52

What causes the error #18 expected a ")" on a MSP430

1 Answers1