I am having a compile issue with C++ Modules, OpenCV 4.5.5 in VS2022
I get C1001 "Internal Compiler Error"
Whats the best way to fix this?
ClassA.ixx:
module;
#include <opencv2/opencv.hpp>
#include "ClassB.h"
export module ClassA;
export class ClassA
{
public:
cv::Mat myMat_; // <- This line fails to compile
ClassB b_; // <- ok
};
main.cpp
import ClassA;
int main()
{
ClassA a;
return 0;
}
Related
I have a problem of undetected dependencies in a project I'm creating with Visual 2019/CMake/ninja. For a demonstration of this problem I have created a small case with two classes ClassA and ClassB.
The .cpp file of ClassA is:
#include "ClassA.h"
#include "ClassB.h"
ClassA::ClassA()
{}
ClassA::~ClassA()
{}
void ClassA::callPrivateB()
{
ClassB toto;
toto.privateFct();
}
The .h file of ClassB is:
#pragma once
class ClassB
{
public:
ClassB();
~ClassB();
void privateFct();
};
And the main.cpp is:
#include <ClassA.h>
int main(int argc, char* argv[])
{
ClassA toto;
toto.callPrivateB();
return 0;
}
Note: ClassA.h, ClassB.cpp, and CMakeLists.txt are not added too do not put to many code.
I'm compiling this application. Everything works well. That is normal. Now, I'm changing the file ClassB.h to put privateFct private. Then I request to recompile the application. And the result is:
ninja: no work to do.
Generate all: OK.
So, the fact that ClassA.cpp depends of ClassB.h has not been detected by ninja? cmake? Visual?
Any idea on how to solve this problem?
base1.h
void base2::base22fun()
{
cout<<"inside base2::base22fun()"<<endl;
}
base1.cpp
#include "base1.h"
#include "iostream"
using namespace std;
void base1::base1fun()
{
cout<<"inside base1::base1fun()"<<endl;
}
base2.h
class base2
{
public:
virtual void base2fun();
};
base2.cpp
#include "base2.h"
#include "iostream"
using namespace std;
void base2::base2fun()
{
cout<<"inside base2::base2fun()"<<endl;
}
derived.h
#include "base1.h"
#include "base2.h"
class derived : public base1, public base2
{
public:
virtual void base1fun();
virtual void base2fun();
};
derived.cpp
#include "derived.h"
#include "iostream"
using namespace std;
void derived::base1fun()
{
cout<<"inside derived::base1fun"<<endl;
}
void derived::base2fun()
{
cout<<"inside derived::base2fun"<<endl;
}
global.cpp
#include "derived.h"
static derived d;
base1& b1=d;
base2& b2=d;
main.cpp
#include "base2.h"
#include "iostream"
using namespace std;
int main()
{
extern base2& b2;
cout<<b2.base2fun();
return 0;
}
I generated object file of all .cpp files using g++ base1.cpp base2.cpp derived.cpp global.cpp main.cpp -c
Then I linked them all, it worked fine.
Now I modified base2.h base2.cpp and main.cpp as follows
base2.h
class base2
{
public:
int padding;
virtual void base22fun();
virtual void base2fun();
};
base2.cpp
#include "base2.h"
#include "iostream"
using namespace std;
void base2::base22fun()
{
cout<<"inside base2::base22fun()"<<endl;
}
void base2::base2fun()
{
cout<<"inside base2::base2fun()"<<endl;
}
main.cpp
#include "base2.h"
#include "iostream"
using namespace std;
int main()
{
extern base2& b2;
cout<<b2.padding;
return 0;
}
I then recompiled base2.cpp, derived.cpp and main.cpp
I didn't recompile global.cpp, and used the old object file[global.o], and g++ linked them and the executable executed. How is this possible?
Thanks.
First of all, learn to use a makefile. That way, you don't have to type so much...
The linker will succeed as long as the required global symbols are present - in this case, the constructor of the class and probably the vtable of the class. Your object takes up extra space after the recompile, so it will overwrite another variable. If you were to add:
static int x = 42;
after static derived d; - and not initialize padding in the constructor, you'd see padding printed as 42.
And all of this is "undefined behaviour". It is allowed to fail in any plausible way - format your hard-disk, start world war III, or "kind of work with subtle side-effects". Using a makefile with the relevant dependencies set so that you automatically recompile objects.cpp whenever base2.h changes would be the right thing to do.
the object "static derived d;" is created when you run your exe. it has nothing to do with complie and link. so it worked.
In common IDEs (pick one) you often have an outline view showing you the list of methods for a specific class.
Suppose I have a C++ interface class in IFoo.h that looks like this:
#ifndef IFOO_H_
#define IFOO_H_
class IFoo {
public:
virtual ~IFoo() {}
virtual void bar() = 0;
};
#endif
How (programmatically) can I get such an IDE outliner list for my IFoo.h file above using maybe the clang libraries? For a first start, it would help if I can get a list of names of functions.
I specifically intend to use clang, so any help on how to analyze the my header file with clang would be really appreciated.
Meanwhile I will have a look at the clang tutorial here: https://github.com/loarabia/Clang-tutorial
Thanks in advance for your help.
I went through this tutorial http://clang.llvm.org/docs/LibASTMatchersTutorial.html and found some pretty helpful stuff there, this is what I came up with:
I had to rename my file from IFoo.h to IFoo.hpp to be detected as Cxx and not C code.
I had to call my program with -x c++ to have my IFoo.h file being recognized as C++ code rather than C code (clang interprets *.h files as C by default:
~/Development/llvm-build/bin/mytool ~/IFoo.h -- -x c++
This is my code to dump all virtual functions from the provided class:
// Declares clang::SyntaxOnlyAction.
#include "clang/Frontend/FrontendActions.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
#include "clang/ASTMatchers/ASTMatchers.h"
// Declares llvm::cl::extrahelp.
#include "llvm/Support/CommandLine.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
#include <cstdio>
using namespace clang;
using namespace clang::ast_matchers;
using namespace clang::tooling;
using namespace llvm;
DeclarationMatcher methodMatcher = methodDecl(isVirtual()).bind("methods");
class MethodPrinter : public MatchFinder::MatchCallback {
public :
virtual void run(const MatchFinder::MatchResult &Result) {
if (const CXXMethodDecl *md = Result.Nodes.getNodeAs<clang::CXXMethodDecl>("methods")) {
md->dump();
}
}
};
// CommonOptionsParser declares HelpMessage with a description of the common
// command-line options related to the compilation database and input files.
// It's nice to have this help message in all tools.
static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
// A help message for this specific tool can be added afterwards.
static cl::extrahelp MoreHelp("\nMore help text...");
int main(int argc, const char **argv) {
cl::OptionCategory cat("myname", "mydescription");
CommonOptionsParser optionsParser(argc, argv, cat, 0);
ClangTool tool(optionsParser.getCompilations(), optionsParser.getSourcePathList());
MethodPrinter printer;
MatchFinder finder;
finder.addMatcher(methodMatcher, &printer);
return tool.run(newFrontendActionFactory(&finder));
}
The output looks like this, when passed the IFoo.h file:
CXXDestructorDecl 0x1709c30 <~/IFoo.h:5:3, col:20> ~IFoo 'void (void)' virtual
`-CompoundStmt 0x1758128 <col:19, col:20>
CXXMethodDecl 0x1757e60 <~/IFoo.h:6:3, col:24> bar 'void (void)' virtual pure
I have a problem with a static library build with Xcode 4.6.2 using the LLVM Clang Compiler. The problem occurs only if I use the C/C++ Compiler flag visibility=hidden. The Linker reports me a duplicate symbol error. I will explain the setup in an easy scenario and I hope someone can explain why this happen.
Imagine I have two classes ClassA and ClassB which I compile into a static library myLib. As said above, I set the Compiler flag -fvisibility=hidden.
Then I have a project which creates an executable from a main.cpp which uses the myLib.
Here are the classes:
ClassA.h
#pragma once
#include <boost/exception/all.hpp>
struct my_error : virtual std::exception, virtual boost::exception {};
class ClassA
{
public:
explicit ClassA() {};
virtual ~ClassA() {};
virtual void doSomething();
};
ClassA.cpp
#include "ClassA.h"
void ClassA::doSomething()
{
BOOST_THROW_EXCEPTION( my_error() << boost::errinfo_api_function("doSomething") );
}
ClassB.h
#pragma once
#include "ClassA.h"
class ClassB
{
public:
explicit ClassB() {};
virtual ~ClassB() {};
virtual void doSomething();
};
ClassB.cpp
#include "ClassB.h"
void ClassB::doSomething()
{
BOOST_THROW_EXCEPTION( my_error() << boost::errinfo_api_function("doSomething") );
}
These two classes a build into my library without a problem. In my executable project which links the myLib I have the following main.cpp
main.cpp
#include <iostream>
#include "ClassA.h"
#include "ClassB.h"
int main(int argc, const char * argv[])
{
ClassA A;
ClassB B;
return 0;
}
The C++ flags:
The build results in the following errors:
duplicate symbol __ZTIPN5boost21errinfo_api_function_E in:
/Users/georg/Library/Developer/Xcode/DerivedData/ExceptionTest-dcnvciwqbwqvciaokkjjaqchftll/Build/Products/Debug/libExceptionLib.a(ClassA.o)
/Users/georg/Library/Developer/Xcode/DerivedData/ExceptionTest-dcnvciwqbwqvciaokkjjaqchftll/Build/Products/Debug/libExceptionLib.a(ClassB.o)
duplicate symbol __ZTSPN5boost21errinfo_api_function_E in:
/Users/georg/Library/Developer/Xcode/DerivedData/ExceptionTest-dcnvciwqbwqvciaokkjjaqchftll/Build/Products/Debug/libExceptionLib.a(ClassA.o)
/Users/georg/Library/Developer/Xcode/DerivedData/ExceptionTest-dcnvciwqbwqvciaokkjjaqchftll/Build/Products/Debug/libExceptionLib.a(ClassB.o)
ld: 2 duplicate symbols for architecture i386 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
If I change the Compiler Flags to the following it works:
The problem is the boost::errinfo_api_function object, but I do not understand why?
I hope someone can help me.
Kind Regards
Georg
I did not realize in a .dll library object types that depends on things that happen at compile time can case problems until I read the question Could I ignore C4251 warning in this case? In deed, if the library compilation settings for the library and the program that uses the library are different, some errors can occur. Here is an example:
dll.h
#include <iostream>
#include <string>
using namespace std;
class __declspec(dllexport) HelloWorld
{
public:
#ifdef DTEST
int test;
#endif
HelloWorld();
};
dll.cpp
#include "dll.h"
HelloWorld::HelloWorld()
{
#ifdef DTEST
test=0;
#endif
}
exe.cpp
#include "dll.h"
#include <iostream>
using namespace std;
int main(void)
{
HelloWorld myworld;
return 0;
}
If I compile dll.h and dll.cpp to create dll.lib and dll.dll with the definition of DTEST but compile exe.cpp without the definition of DTEST. I will have a runtime check failure #2 error. Could some explain why I have this error. Thanks!
You have this error because DTEST is a preprocessor macro and you are not defining it consistently for all pieces of your program. It is completely removed by the time your code reaches the actual compiler, so the compiler won't catch the problem. If you define DTEST for dll.cpp but not for exe.cpp, then exe.cpp will look like this to the compiler:
(...contents of <iostream>...)
(...contents of <string>...)
using namespace std;
class __declspec(dllexport) HelloWorld
{
public:
HelloWorld();
};
(...contents of <iostream> again...)
using namespace std;
int main(void)
{
HelloWorld myworld;
return 0;
}
However, dll.cpp will look like this:
(...contents of <iostream>...)
(...contents of <string>...)
using namespace std;
class __declspec(dllexport) HelloWorld
{
public:
int test;
HelloWorld();
};
HelloWorld::HelloWorld()
{
test=0;
}
The problem here is dll.cpp and exe.cpp have two different ideas of what HelloWorld is: dll.cpp thinks it contains test, but exe.cpp thinks it doesn't. There is a runtime check that catches this mismatch, which is what you're seeing.
What the compiler sees is the results of preprocessor expansion.
In your example, the compiler sees:
class HelloWorld
{
public:
int test;
HelloWorld();
};
in dll.cpp, and
class HelloWorld
{
public:
HelloWorld();
};
in exe.cpp. Same class, two different definitions. That's
a violation of the one definition rule, which results in
undefined behavior.
This has nothing to do with the C4251 warning (which if
I understand correctly, only concerns linking between different
DLLs).