I follow the instructions for build xerces in linux
./configure
make
make install
But I'm trying to run the first example from Programming Guide
#include <xercesc/util/PlatformUtils.hpp>
// Other include files, declarations, and non-Xerces-C++ initializations.
using namespace xercesc;
int main(int argc, char* argv[])
{
try {
XMLPlatformUtils::Initialize();
}
catch (const XMLException& toCatch) {
// Do your failure processing here
return 1;
}
// Do your actual work with Xerces-C++ here.
XMLPlatformUtils::Terminate();
// Other terminations and cleanup.
return 0;
}
But I'm getting a few errors:
=== Build: Debug in vasprun_xml (compiler: GNU GCC Compiler) ===
vasprun_xml/main.cpp|22|reference to `xercesc_3_1::XMLUni::fgXercescDefaultLocale' not define
vasprun_xml/main.cpp 22reference to `xercesc_3_1::XMLPlatformUtils::Initialize(char const*, char const*, xercesc_3_1::PanicHandler*, xercesc_3_1::MemoryManager*)' not define
How can I solve this issues?
Anon Mail has reason.
The problem is that Code::Blocks not auto detect system dynamic library.
We need go to
Project->Build Options->Linker Settings
and than add the the name of your library (in our case xerces-c-3.1) without lib prefix. Ok and than build and run without erros.
Is like do
g++ -o main main.cpp /path-to-your-lib/src/.libs/libxerces-c-3.1.so
Related
I am trying to build a simple test using gtest on the latest version of Visual Studio 2017. The code is the following:
#include "pch.h"
#include <gtest/gtest.h>
struct BankAccount
{
int balance = 0;
BankAccount()
{
}
explicit BankAccount(const int balance)
: balance{ balance }
{
}
};
TEST(AccountTest, BankAccountStartsEmpty)
{
BankAccount account;
EXPECT_EQ(0, account.balance);
}
int main(int argc, char* argv[])
{
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
And the build error is:
Error C4996 'std::tr1': warning STL4002: The non-Standard std::tr1 namespace and TR1-only machinery are deprecated and will be REMOVED.
You can define _SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING to acknowledge that you have received this warning.
I already tried:
#define _SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING
But it just makes things worse.
I dont know how to fix this error.
UPDATE
I tried adding the define in the preprocessor's definitions and above the includes. Neither works!!
Try going to:
View -> Properties -> C/C++ -> Preprocessor
and Set Preprocessor Definitions as _SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING
Also another solution is to re-enable TR1 by defining _HAS_TR1_NAMESPACE.
However, disabling error is not a good idea. Your warning may be present due to incorrect project setting and you should inform gtest that your compiler version supports
newer C++ versions by setting GTEST_LANG_CXX11 to be 1.
I am running my simple C++ program in OMNET ++ IDE
My code is as follows
**#include <stdio.h> // for printf
#include <string.h>
#include <SQLAPI.h> // main SQLAPI++ header
//#include <asaAPI.h>
int main(int argc, char* argv[])
{
SAConnection con;
con.setOption( "UseAPI" ) = "DB-Library";
con.setClient( SA_SQLServer_Client );
try
{
con.Connect(
"paper2"
"NADRA",
"",
SA_SQLServer_Client);
printf("We are connected!\n");
// Disconnect is optional
// autodisconnect will occur in destructor if needed
//con.Disconnect();
printf("We are disconnected!\n");
}
catch(SAException &x)
{
// SAConnection::Rollback()
// can also throw an exception
// (if a network error for example),
// we will be ready
try
{
// on error rollback changes
//con.Rollback();
}
catch(SAException &)
{
}
// print error message
printf("%s\n", (const char*)x.ErrText());
}
return 0;
}**
I have already linked all the files but the error that i am getting is as follow
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lC:\SQLAPI\lib\sqlapi.lib
collect2.exe: error: ld returned 1 exit status
Where as the file sqlapi.lib is in the same folder but linker is not able to find it. Can someone tells me about the issue that why compiler is not able to link it .I am using MINGW as a C++ compiler. The screen shot is attached by with the question about the linked filesenter image description here
If you are using -l, then it should be followed by the library name only, so something like:
-lsqlapi
If you want to specify a search path, then:
-lsqlapi -LC:\SQLAPI\lib\
(Usually the path is in Linux mode, so `C:/SQLAPI/lib though).
Then if this doesn't work, you can always force the library to be linked by just using it as another object:
C:/SQLAPI/lib/sqlapi.lib
Note though that gcc doesn't link against Visual Studio static libraries, which sqlapi might (because of the extension being .lib and not .a, but then this may be the export library for a dll).
I'm just learning c++. I have a main.cpp unit which has a lot of stuff in it already, and I just want to build a quick little testMain.cpp unit that will test a couple of things.
Basically I want to trick the compiler (xCode) into ignoring the real main function for a minute. I could
Rename the main() function inside main.cpp to mmain() temporarily.
Remove the reference to main.cpp in my project temporarily.
Comment out the main() method in main.cpp temporarily.
All these seem pretty clunky. There has to be an easier way. I suspect this is a common thing people do. How do you do it?
Another solution would be to separate the code into multiple files, have most of the logic in one file, have the real main in another and the test main in a third, you compile and link either the first and second or first and third files but never all three together.
Your option 2 is the most common strategie, and from my understanding also the cleanest.
After all, your test application will most likely not share the same command line interface, and that is usually about the only thing which should (of at all) be located in the main function or file.
If your main.cpp contains significantly more than just the entry point, you should immediately start thinking about how to distribute that logic into the modules you already have.
Use a macro.
Option 1: Use a macro to include/exclude entire files:
main.cpp:
#ifdef USE_REAL_MAIN
int main(int argc, char* argv[]) {
...
}
#endif
testMain.cpp
#ifdef USE_TEST_MAIN
int main(int argc, char* argv[]) {
...
}
#ENDIF
build file:
gcc -DUSE_REAL_MAIN
gcc -DUSE_TEST_MAIN
Option 2: Use a command-line macro to rename main:
main.cpp:
int realMain(int argc, char* argv[]) {
...
}
testMain.cpp
int testMain(int argc, char* argv[]) {
...
}
build file:
gcc -DrealMain=main
gcc -DtestMain=main
Note this is probably the least attractive option because it breaks the convention of macros having UPPER_CASE names and means the real entrypoint of your program is non-obvious to someone who hasn't seen the build script. It also means the program simply won't compile (as there's no main function) without your custom build script either.
Option 3: Have a new common main with the #ifdef directives instead:
main.cpp
#include "realMain.h"
#include "testMain.h"
int main(int argc, char* argv[]) {
#ifdef USE_TEST_MAIN
return testMain( argc, argv );
#else
return realMain( argc, argv );
#endif
}
build file:
gcc -DUSE_REAL_MAIN
gcc -DUSE_TEST_MAIN
I think this is my preferred option because it's almost self-documenting and makes it clear to another programmer how to get it to work without needing your custom build script.
I try to compile my very first program in C++ in which I try to connect to ZooKeeper and do some other stuff. In my code I have these lines:
//test.cpp
#include "zookeeper.h"
... all other header files from zookeeper/include
void main_watcher (zhandle_t *zkh,
int type,
int state,
const char *path,
void* context)
{
if(type == ZOO_SESSION_EVENT){
if(state == ZOO_CONNECTED_STATE){
...
}
...
}
}
int main(){
return 0;
}
But when I compile this test.cpp file (indeed, I provide link to the zookeeper/.../build/usr/lib and path to all included files), I get a list of these error messages:
undefined reference to ZOO_SESSION_EVENT
undefined reference to ZOO_CONNECTED_STATE
...
What am I doing wrong?
You're forgetting to link agains zookeeper, most probably. Typically, you'd have to do something like
g++ -lzookeper -o yourprogram yourprogram.c
maybe it's
-lzookeeper-mt
maybe not. Usually, it's job of a build system to figure these things out for you.
I've just learned about value-parametrized unit tests in googletest and would like to use them in my project.
I wrote a simple parametrized test.
Header:
#include <gtest/gtest.h>
namespace EnsembleClustering {
class ParametrizedGTest: public testing::TestWithParam<int> {
public:
ParametrizedGTest();
virtual ~ParametrizedGTest();
};
} /* namespace EnsembleClustering */
Source:
#include "ParametrizedGTest.h"
namespace EnsembleClustering {
ParametrizedGTest::ParametrizedGTest() {
// TODO Auto-generated constructor stub
}
ParametrizedGTest::~ParametrizedGTest() {
// TODO Auto-generated destructor stub
}
TEST_P(ParametrizedGTest, testParameter) {
int n = GetParam();
EXPECT_EQ(n, GetParam());
}
INSTANTIATE_TEST_CASE_P(ParametrizedGTestInstance,
ParametrizedGTest,
::testing::Values(100));
} /* namespace EnsembleClustering */
Now, when I run googletest as usual, the program crashes without any output. The gdb stack trace is
EnsembleClustering-D [C/C++ Application]
EnsembleClustering
Thread [1] (Suspended : Signal : EXC_BAD_ACCESS:Could not access memory)
__gnu_debug::_Safe_sequence_base::_M_attach_single() at 0x100528add
__gnu_debug::_Safe_sequence_base::_M_attach() at 0x100528a74
__gnu_debug::_Safe_iterator_base::_M_attach() at 0x100528bfe
__gnu_debug::_Safe_iterator_base::_Safe_iterator_base() at safe_base.h:90 0x1000016e9
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<testing::internal::ParameterizedTestCaseInfoBase**, std::__cxx1998::vector<testing::internal::ParameterizedTestCaseInfoBase*, std::allocator<testing::internal::ParameterizedTestCaseInfoBase*> > >, std::__debug::vector<testing::internal::ParameterizedTestCaseInfoBase*, std::allocator<testing::internal::ParameterizedTestCaseInfoBase*> > >::_Safe_iterator() at safe_iterator.h:154 0x100002e9c
std::__debug::vector<testing::internal::ParameterizedTestCaseInfoBase*, std::allocator<testing::internal::ParameterizedTestCaseInfoBase*> >::begin() at vector:207 0x100001fbe
testing::internal::ParameterizedTestCaseRegistry::GetTestCasePatternHolder<EnsembleClustering::ParametrizedGTest>() at gtest-param-util.h:574 0x1000025b0
EnsembleClustering::ParametrizedGTest_testParameter_Test::AddToRegistry() at ParametrizedGTest.cpp:22 0x100001d3f
__static_initialization_and_destruction_0() at ParametrizedGTest.cpp:22 0x100001349
_GLOBAL__sub_I_ParametrizedGTest.cpp() at ParametrizedGTest.cpp:32 0x100001424
<...more frames...>
gdb
Am I doing something wrong or is this a bug in googletest? Can you reproduce this error?
EDIT: I am on Mac OS X 10.8.
From looking at the source code of gtest the only case if there are no parametrized tests available is on Windows using VC7.1 with disabled exceptions:
// We don't support MSVC 7.1 with exceptions disabled now. Therefore
// all the compilers we care about are adequate for supporting
// value-parameterized tests.
#define GTEST_HAS_PARAM_TEST 1
So, you'll need to check how your MinGW was built and probably update it? And can you run the gtest unit tests to see if they execute the typed parameters test?
More information on MinGW:
On their FAQ they report that when using MinGW the following compile option for building gtest is required: PATH/TO/configure CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin".
Complete Example:
#include <gtest/gtest.h>
namespace EnsembleClustering {
class ParametrizedGTest: public testing::TestWithParam<int> {
public:
ParametrizedGTest();
virtual ~ParametrizedGTest();
};
ParametrizedGTest::ParametrizedGTest() {
}
ParametrizedGTest::~ParametrizedGTest() {
}
TEST_P(ParametrizedGTest, testParameter) {
int n = GetParam();
EXPECT_EQ(n, GetParam());
}
INSTANTIATE_TEST_CASE_P(ParametrizedGTestInstance,
ParametrizedGTest,
::testing::Values(100));
} /* namespace EnsembleClustering */
int main(int argc, char* argv[]) {
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
I compiled this code using the following compiler call on Mac OS X 10.8:
g++ -IGTEST_INCLUDE_DIR -LGTEST_LIB_DIR -lgtest -o tt2 tt2.cpp
Where GTEST_INCLUDE_DIR and GTEST_LIB_DIR are the path where header and library files are stored. When you compile and execute, what happens?
Thanks #ChristianStaudt and #grundprinzip
I would like to point future readers to following link that explains this problem.
http://libcwd.sourceforge.net/reference-manual/group__enable__glibcxx__debug.html
This is a link to the documentation for GLIBCXX_DEBUG flag. It states the following important points.
"Note that this flag changes the sizes and behavior of standard class templates such as std::vector, and therefore you can only link code compiled with debug mode and code compiled without debug mode if no instantiation of a container is passed between the two translation units."
"When to use it
It is a good idea to use this if you suspect problems related to iterators."
Now, if you look at the stack trace posted originally, the crash happens due to vector<testing::internal::ParameterizedTestCaseInfoBase*> as gtest tries to get an iterator on this container, using begin() method.
In my case, gtest lib was compiled without GLICXX_DEBUG flag, but my test code was compiled with this flag. The test code worked like a charm when I compiled without this flag.