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

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?

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.

Related

Compiler/linker complaining about function definition not found in C++

I've done this so many times, yet the reason why Visual Studio is complaining about this escapes me.
Manipulator.cpp:
#include "Manipulator.h"
Manipulator::Manipulator() {}
Manipulator::~Manipulator() {}
void proc(std::string p, int f, std::string c)
{
// switch-case p to c based on f:
return;
}
Manipulator.h: (void -proc- has a curly underscore, and that's what's driving me up the wall.)
#ifndef MANIPULATOR_H
#define MANIPULATOR_H
#include <string>
class Manipulator
{
private:
protected:
public:
Manipulator() ;
~Manipulator() ;
void proc(std::string, int, std::string);
// function definition for 'proc' not found.
};
#endif MANIPULATOR_H
main.cpp
#include "Manipulator.h"
...
int main()
{
...
Manipulator m;
...
m.proc(opdBMP, fxn, newBMP);
return 0;
}
What is it that VS wants so that I can get a move on? It is telling me that there are two linker errors: LNK2019 and LNK1120 (unresolved external). (I used to keep track of these kinds of errors but lost the file as a log with these.)
The compiler is correct in complaining, because the definition should be
void Manipulator::proc(std::string p, int f, std::string c) {
...
}
You just defined a free function instead of a member of Manipulator.

Accessing Methods in Declaration vs Implementation

I'm having difficulty interpreting some of my results, which I would expect to behave the same but are not.
I am trying to write a method that returns a function pointer getPtrFn
I have a main.c file reading
#include <iostream>
#include "test.hpp"
int main(int argc, char* argv[]){
Test test;
void (*fPtr)(void) = test.getPtrFn();
return 0;
}
A test.hpp file that reads
#ifndef _test_h
#define _test_h
class Test {
private:
void (*ptrFn)(void);
public:
Test(){};
void (*getPtrFn(void))(void){
return ptrFn;
};
~Test();
};
#endif
And a test.cpp file that reads
#include "test.hpp"
Test::~Test(){}
This runs fine. However, when I move the implementation for *getPtrFn(void) to the implementation file (revised files shown below),
test.hpp:
#ifndef _test_h
#define _test_h
class Test {
private:
void (*ptrFn)(void);
public:
Test(){};
void (*getPtrFn(void))(void);
~Test();
};
#endif
test.cpp:
#include "test.hpp"
void (Test::*getPtrFn)(void){
return ptrFn;
};
Test::~Test(){}
I get the compile error
test.cpp:16:9: error: use of undeclared identifier 'ptrFn'
My understanding of the language syntax is that they would be treated the same. So what gives?
-Jeff
You need
void(*Test::getPtrFn(void))(void)
{
return ptrFn;
}
instead of void (Test::*getPtrFn)(void){...}. void (Test::*getPtrFn)(void) is the declaration of getPtrFn as a pointer-to-Test-member-function taking no parameters (void) and returning void, so after you put the braces { ... } you get a compile-time error (its like trying to declare int i{/*some statemets*/}).
Also, and don't forget to keep the declaration
void(*getPtrFn(void))(void);
in your header (right now it seems you don't have it, did you cut/pasted it?).
Quite a horrible thing to look at... So really, use a type alias, it makes your code much cleaner.
using PTRFN = void(*)(void); // or typedef void(*PTRFN)(void);
class Test {
private:
PTRFN ptrFn;
public:
PTRFN getPtrFn(void);
Test(){};
~Test(){};
};
PTRFN Test::getPtrFn(void) // clear an concise
{
return ptrFn;
}
In case you really really want to be able do decipher every kind of pointer declaration you can think of, try looking at the clockwise/spiral rule, I found it extremely useful, clear and easy to understand. Then test your knowledge at cdecl.org.

Nested vectors in Linux

I'm trying to implement a DivideAndConquer template. The original project was in VisualStudio 2013, but when I move the source code to Linux I get errors.
#pragma once
#include <vector>
using namespace std;
template <typename Element>
class DivideAndConquer
{
public:
~DivideAndConquer(){}
vector<Element> solve(vector<Element> p);
protected:
virtual bool isSimple(vector<Element> p) = 0;
virtual vector<Element> simplySolve(vector<Element> p) = 0;
virtual vector<vector<Element>> decompose(vector<Element> p) = 0;
virtual vector<Element> combine(vector<vector<Element>> p) = 0;
};
The error reads DivideAndConquer.h:28: error: a function call cannot appear in a constant-expression. I have comments in my version, so line 28 is the declaration of the decompose function. There are similar errors for all declarations involving nested vectors across all other .h files.
Does Linux allow nested vectors in this fasion? I really don't want to keep track of an array's size throughout my whole implementation.
You are blaming linux for your minor mistake...
virtual vector<vector<Element>> decompose(vector<Element> p) = 0;
This should be :-
virtual vector<vector<Element> > decompose(vector<Element> p) = 0;
>> should be separated > >

Why doesn't Xcode recognize free() and malloc() in this .cpp file?

I have many .cpp files in my project that work. But this one irritates Xcode or the compiler.
It doesn't recognise free() and malloc() but this is also C. What can be wrong?
Header ssdpmessage.h looks like this:
#ifndef _SSDPMESSAGE_H
#define _SSDPMESSAGE_H
#include "ssdptools.h"
#include <vector>
#include <arpa/inet.h>
#include "ssdpdb.h"
class SSDPMessage{
public:
SSDPMessage();
virtual ~SSDPMessage();
//What type of message can we handle
virtual SSDP_TYPE GetType()=0;
//Get the message dignature implemented in this class
virtual std::vector<SSDP_HTTP_HEADER*> GetHeaderSignature();
//Can this class parse the message with this signature ?
virtual u8 CanProcess(std::vector<SSDP_HTTP_HEADER*> msgheaders);
//Process the message, return value:
//0 : processed
//1 : not for me, search for another to process
//<0 : message was for me but there is an error
virtual int Process(struct sockaddr* sender, std::vector<SSDP_HTTP_HEADER*> msgheaders)=0;
//ReInit all members
virtual void ReInit()=0;
virtual SSDPDB* GetDB();
virtual void SetDB(SSDPDB* db);
private:
std::vector<SSDP_HTTP_HEADER*> mHeaderSignature;
protected:
int AddSignatureHeader(char* fieldname, char* fieldvalue);
SSDPDB *mDB;
private:
SSDPMessage(const SSDPMessage &src);
SSDPMessage& operator= (const SSDPMessage &src);
};
#endif //_SSDPMESSAGE_H
The includes and affected code in ssdpmessage.cpp look like this:
#include "ssdpmessage.h"
SSDPMessage::SSDPMessage():mDB(NULL){
}
SSDPMessage::~SSDPMessage(){
std::vector<SSDP_HTTP_HEADER*>::iterator it;
for(it=mHeaderSignature.begin(); it<mHeaderSignature.end(); it++){
free(*it);
}
mHeaderSignature.clear();
}
int SSDPMessage::AddSignatureHeader(char* fieldname, char* fieldvalue){
SSDP_HTTP_HEADER *thisHeader = (SSDP_HTTP_HEADER*)malloc(sizeof(SSDP_HTTP_HEADER));
thisHeader->fieldname = (u8*)fieldname;
thisHeader->fieldnamelen = strlen(fieldname);
thisHeader->fieldvalue = (u8*)fieldvalue;
thisHeader->fieldvaluelen = strlen(fieldvalue);
mHeaderSignature.push_back(thisHeader);
return mHeaderSignature.size();
}
This is code from the upnpx library. It works without problem in the demo project of the library.
malloc requires you to include cstdlib.

g++ 4.2: internal compiler error: in make_thunk, at cp/method.c:129

I asked this question already on http://www.cplusplus.com/forum/general/96128/ but to no avail.
does anybody experienced the same bug with g++ 4.2: internal compiler error: in make_thunk, at cp/method.c:129
I think it is not neccessary to include sample code. The respective code compiles without warnings and errors on several other newer g++ versions, as well as on clang++. It is simply correct and the bug was mentioned in the GCC's bugzilla (even several times, because it seems to recurr often), but no workaround was provided.
Please don't tell also to use a newer g++. I MUST compile it on the g++ shipped with Ubuntu Hardy, so I cannot change the compiler. Main development is done on Ubuntu Precise, but I need to keep it compatible to Hardy.
I have no idea what a thunk should be, I only suspect it has to do with covariants and/or multiple inheritance. Also I have several more similar structured header files, which all compile well, despite the only change is the name is the name of the class and I have no aim, to change that because of a compiler bug on Hardy.
Another fact is, it happens at include time.
In file included from /home/heiko/hgl/src/compiler/compilerprojectfactory.cpp:18:
/home/heiko/hgl/src/compiler/compilertype.h: In instantiation of 'HGL::Compiler::CompilerType<HGL::Vector2D, HGL::Compiler::CompilerBase>':
/home/heiko/hgl/src/compiler/compilervector2d.h:23: instantiated from here
/home/heiko/hgl/src/compiler/compilertype.h:22: internal compiler error: in make_thunk, at cp/method.c:129
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.2/README.Bug
EDIT: Here the header which causes the bug:
#include "compilertype.h"
#include "vector2d.h"
namespace HGL {
class Vector2D;
namespace Compiler {
/**
#author Heiko Schäfer <heiko#rangun.de>
*/
class _LOCAL Vector2D : public Compiler::CompilerType<HGL::Vector2D> {
DISALLOW_COPY_AND_ASSIGN(Vector2D)
public:
Vector2D(float x, float y, int line);
using IType::operator=;
virtual operator HGL::Vector2D &() const throw(InvalidExpressionException);
protected:
virtual ~Vector2D();
void append(ISerializeable::BUFFER *dest, const HGL::IType *type) const;
};
}
}
Here the template:
#include "compilerbase.h"
#include "iproject.h"
#include "util.h"
namespace HGL {
namespace Compiler {
const IProject::VSTRUCT minReq = { HGL_MINREQ_MAJOR, HGL_MINREQ_MAJOR, HGL_MINREQ_MAJOR };
template<class Type, class Base = CompilerBase>
class _LOCAL CompilerType : public Type, public Base {
DISALLOW_COPY_AND_ASSIGN(CompilerType)
public:
using IType::operator=;
template<class Param>
inline CompilerType(const Param &p, bool b, int line,
const IProject::VSTRUCT &vs = IProject::VSTRUCT()) :
Type(p), Base(line, b) {
init(vs);
}
template<class Param>
inline CompilerType(const Param &p, int line,
const IProject::VSTRUCT &vs = IProject::VSTRUCT()) : Type(p), Base(line) {
init(vs);
}
inline CompilerType(bool b, int line, const IProject::VSTRUCT &vs = IProject::VSTRUCT())
: Type(), Base(line, b) {
init(vs);
}
template<class Param1, class Param2>
inline CompilerType(const Param1 &p1, const Param2 &p2, int line,
const IProject::VSTRUCT &vs = IProject::VSTRUCT()) :
Type(p1, p2), Base(line) {
init(vs);
}
template<class Param1, class Param2>
inline CompilerType(const Param1 &p1, const Param2 &p2, bool b, int line,
const IProject::VSTRUCT &vs = IProject::VSTRUCT()) : Type(p1, p2),
Base(line, b) {
init(vs);
}
inline CompilerType(int line,
const IProject::VSTRUCT &vs = IProject::VSTRUCT()) : Type(), Base(line) {
init(vs);
}
inline virtual void append(ISerializeable::BUFFER *dest, const IType *type) const {
Base::append(dest, type);
}
protected:
inline virtual ~CompilerType() {}
inline virtual void init(const IProject::VSTRUCT &vs) {
const_cast<IProject::VSTRUCT &>(vs) = std::max(vs, minReq);
CompilerBase::setMinRequiredVersion(vs, Type::getSerialID());
}
};
}
}
RESOLVED!
After digging in g++ 4.2's source code I found out that it needs to now about all types in the complete tree. g++ > 4.2 apparently doesn't need this.
So, the error was in a related class which had a template member with a forwarded specialization. I just included the header instead of forwarding and g++ 4.2 was happy.
Otherwise it is really a non-nice bug not to give an error, but this useless message.
A thunk or trampoline is a piece of code that is added in some implementations of dynamic dispatch to adapt the interface of the base virtual function with respect to the final overrider being used. As you mentioned it is commonly needed to adapt the this pointer in multiple/virtual inheritance (for bases listed after the first non-empty one) and to adapt the resulting pointer/reference with covariant return types.
The error indicates that it is a compiler bug. If you have to use that particular compiler you will need to work around the issue, and that will involve changing your design. You can try to limit the use of multiple/virtual inheritance, reorder the bases in the list or try to play around until you manage to get the compiler to digest that code somehow. If it is a problem when generating the adapter for a covariant return type, consider removing the covariant return and provide an overload (with a different name) that will return the covariant type (i.e. replace covariant return with a non-virtual function returning the most derived type and a virtual function that calls the previous and returns a reference to the base).
Other than those generic hints, without seeing the code you have and the implementation of the compiler there is little else to say.