Do I need to build TinyThread++? - c++

I've extracted the sources from the zip file at the website and put them in Code::Blocks' 'include' folder, but even then it cannot compile the provided 'hello.cpp' example.
(For reference:)
#include <iostream>
#include <tinythread.h>
using namespace std;
using namespace tthread;
// This is the child thread function
void HelloThread(void * aArg)
{
cout << "Hello world!" << endl;
}
// This is the main program (i.e. the main thread)
int main()
{
// Start the child thread
thread t(HelloThread, 0);
// Wait for the thread to finish
t.join();
}
And these are the following errors:
|41|undefined reference to `tthread::thread::thread(void (*)(void*), void*)'|
|44|undefined reference to `tthread::thread::join()'|
|44|undefined reference to `tthread::thread::~thread()'|
|44|undefined reference to `tthread::thread::~thread()'|
The same thing happens with wxDev-C++. Am I missing something; like, do I need to build the libraries or anything? If so, how?

From the readme.txt inside the archive:
Using TinyThread++
To use TinyThread++ in your own project, just add tinythread.cpp and
tinythread.h to your project. In your own code, do:
#include <tinythread.h>
using namespace tthread;
If you wish to use the fast_mutex class, inlude fast_mutex.h:
#include <fast_mutex.h>
Just including the header leads to unresolved symbols because the .cpp does not get compiled.

TinyThread is tiny.
In additional to including the headers, you just add the TinyThread.cpp to your project or ensure that it builds as part of your project.
The particular error happened to me in VC++ until I added the CPP file to my project.
The thread class and methods were not getting compiled otherwise.

Related

Calling functions from separate C++ files in main.cpp trouble

I have been searching online for solutions to this rather simple problem. My goal is to call a function from a separate .cpp file in my main.cpp file. What I have found thus far has told me to define my function in a separate .cpp file (averageScore.cpp) which looks like:
void averageScore()
{
"Blah, Blah, Blah"
}
And then declare the function as a prototype in a header file (Lesson1.h) which looks like:
#include "C:/averagescore.cpp"
void averageScore();
And finally call the function again in the main.cpp:
#include "Lesson1.h"
int main()
{
averageScore();
return 0;
}
I am currently a CS student and my overall objective with this method of organization and execution is to create a single project for all of the rudimentary programs we must create on a weekly basis instead of creating a new project for every single program. For reference, I am using VScode and have used the following link to help me thus far:
http://www.cplusplus.com/forum/beginner/97779/
My condolences and gratitude are extended to anyone who has taken the time to read through this and help me out!
To achieve what you want, you must create a header file, and declare your function there, for example:
lesson1.h
void averageScore();
In a .cpp file, you define that function and include the header you just created:
lesson1.cpp
#include "lesson1.h"
void averageScore(){
// Do what you want in this function
}
Then you can call that function in your main.cpp by including "lesson1.h":
main.cpp
#include "lesson1.h"
int main()
{
averageScore();
return 0;
}

How to make CPP files visible to linker in ESP8266 Eclipse project

There is a "hello world" project in Eclipse IDE that is supposed to compile against ESP8266 RTOS SDK.
File structure is as follows
I added one C++ class to it and put it into its own folder. Here is the class header
#ifndef MAIN_BLINKER_BLINKER_H_
#define MAIN_BLINKER_BLINKER_H_
class Blinker {
public:
Blinker( int period );
int Period() const;
private:
int period_;
};
#endif /* MAIN_BLINKER_BLINKER_H_ */
and the definitions
#include "Blinker.h"
Blinker::Blinker( int period ) :
period_( period )
{}
int Blinker::Period() const {
return this->period_;
}
Main.cpp file is like this
#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "blinker/Blinker.h"
extern "C" {
void app_main()
{
auto blnk = Blinker( 3000 );
int i = 0;
while ( 1 ) {
printf( "[%d] Hello beautiful world!\n", i );
i++;
vTaskDelay( blnk.Period() / portTICK_PERIOD_MS );
}
}
}
It compiles but fails at final stage because the linker (or what is supposed to be a linker in xtensa toolchain) does not see definitions of Blinker methods. This is what I get in the build log
If I put class files next to main.cpp file, the build succeeds. However with time there will be hundreds of files, and without any grouping it will quickly turn into an unmanageable mess.
Alternatively I could put this class into top-level components folder and equip it with empty component.mk file. This would also make the build system happy, however it would force me to use ugly header includes like ../components/blinker/Blinker.h, which I would like to avoid.
So the question is how to make build system aware of .c and .cpp files residing in subfolders of main folder?
you can set COMPONENT_SRCDIRS in "main" component.mk file
see:
https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/api-guides/build-system.html#example-component-makefiles
Try to add blinker/Blinker.cpp to your CMakeLists.txt.
Take a look at
How to add new source file in CMakeLists.txt?

How c++ includes all functions in specific file without any inclusion of that file?

I just feel weird about how does that work ?
That my first time that I've ever seen that , two c++ files located in the same directory "Test1.cpp,Test2.cpp"
Test1.cpp :
#include <iostream>
void magic();
int main(){
magic();
return 0;
}
Test2.cpp :
#include <iostream>
using namespace std;
void magic(){
cout << "That's not a magic , it's a logical thing.." << endl;
}
As I mentioned above , they are in the same directory , with prototype of 'magic' function.
Now my question is , how does magic work without any inclusion of Test2.cpp ?
Does C++ include it by default ? if that's true , then why do we need to include our classes ? why do we need header file while cpp file can does its purpose ?
In order to obtain an executable from a C++ source code two main phases are required:
compilation phase;
linking phase.
The first one searches only for the signature of the functions and check if the function call is compatible with the found declarations.
The second one searches the implementation of the function among the libraries or objects linked through the options specified through command line of the linker (some compilers can automatically run the linker adding some command line options).
So you need to understand the compiler and linker options in order to understand this process.
The main catch of headers file is simplifying writing of code.
Let's think about next example:
test2.cpp
#include <iostream>
using namespace std;
void my ()
{ magic(); } // here we don't know what magic() is and compiler will complain
void magic(){
cout << "That's not a magic , it's a logical thing.." << endl;
}
This code gives next error:
gaal#linux-t420:~/Downloads> g++ test2.cpp
test2.cpp: In function ‘void my()’:
test2.cpp:6:9: error: ‘magic’ was not declared in this scope
{ magic(); } // here we don't know what magic() is and compiler will complain
^
To avoid this error we need to place declaration of magic() function before definition of my(). So it is good idea to place ALL declarations in one place. Header file is a such place. If we don't use headers, we'll need to paste declaration of magic() function in any cpp-file where it will be used.

Troubles with compiling, static initialization and static libraries

I have recently encountered a behavior in C++ program that I cannot entirely understand. Let me explain the behavior via simple example.
1. First static library
At the very bottom of hierarchy, I have a static library - lets name it FirstLIB. This library includes two pairs of header/source files. The sample.h header file contains MyClass class definition. Corresponding sample.cpp file contains implementation of this class (its methods). The code is presented below:
sample.h
#ifndef __sample_h
#define __sample_h
namespace SampleNamespace
{
class MyClass
{
int counter;
public:
MyClass();
int GetCounter();
void SetCounter(int value);
};
}
#endif
and sample.cpp
#include <iostream>
#include "sample.h"
namespace SampleNamespace
{
MyClass::MyClass(): counter(0)
{
std::cout << "Inside of MyClass constructor!" << std::endl;
}
int MyClass::GetCounter() { return counter; }
void MyClass::SetCounter(int value) { counter = value; }
}
Onwards, the dvcl.h file declares simple API used to manipulate MyClass object and dvcl.cpp implements this API. It's important to notice that dvcl.cpp file contains definition of MyClass object that is used by the methods of this API. The variable is defines as static so it will be visible only inside of this source file.
dvcl.h
#ifndef _dvcl_h
#define _dvcl_h
void DVCL_Initialize(int counter);
int DVCL_GetCounter();
void DVCL_SetCounter(int value);
#endif
dvcl.cpp
#include "dvcl.h"
#include "sample.h"
static SampleNamespace::MyClass myClass;
void DVCL_Initialize(int counter)
{
myClass.SetCounter(counter);
}
int DVCL_GetCounter()
{
return myClass.GetCounter();
}
void DVCL_SetCounter(int value)
{
myClass.SetCounter(value);
}
2. Second static library
Second static library - lets name it SecondLIB - is even simpler than the first one. It only contains one header/source pair. The dvconference_client.h header declares one function, while dvconference_client.cpp implements this function. dvconference_client.cpp also includes dvcl.h header file (which will trigger compilation of dvcl.cpp source). The code can be found below:
dvconference_client.h
#ifndef __external_file
#define __external_file
int DoSomething();
#endif
dvconference.cpp
#include "dvconference_client.h"
#include "dvcl.h"
int DoSomething()
{
return DVCL_GetCounter();
}
3. Main executable
And finally, the main executable MainEXE includes only one main.cpp file. This source includes dvconference_client.h and dvcl.h headers. The code is presented below:
#include <iostream>
#include "dvconference_client.h"
#include "dvcl.h"
int main()
{
std::cout << DoSomething() << std::endl;
std::cout << DVCL_GetCounter() << std::endl;
return 0;
}
4. My doubts and questions:
If I don't call a function that references myClass object (so DoSomething() or one of DVCL_ functions), the MyClass constructor is not invoked. I expected that myClass object will be instantiated by default as dvcl.cpp is compiled. However, it appears that compiler generates needed statements only if it understand that object is actually used in runtime. Is this really true?
If particular header file (in this case dvcl.h) is included in different sources, the corresponding dvcl.cpp is compiled only once. I remember reading something about this, however I'm not sure that this is really true. Is it actually correct that C++ compiler will compile every source file only once, regardless of how many the corresponding header file is included.
myClass object defined in dvcl.cpp is instantiated only once. If I correctly understand the 2nd point and if dvcl.cpp is compiled only once, then there is nothing to question here.
I hope more experienced colleagues can clear my doubts (and I apologize for very long post).
"static SampleNamespace::MyClass myClass; " is both a declaration and definition. So your constructor is invoked and created. Asm-code to instantiate this is generated at compile-time but this is executed at executable-load-time.
For referenec, stages of compilation
source-code --> pre-processing --> compilation --> linking --> loading --> execution
Yes, ".c/.cpp" file are compiled only once. But header are parsed per inclusion.
Yes object is executed only once because corresponding object-file is linked and loaded only once.
First point :
dvcl compilation unit is in a static library. If the code is not used, the compiled object (.o) is not included in resulting executable. As such, static SampleNamespace::MyClass myClass; is never executed. It won't be the same if you were using a dynamic library or explicitely linking the .o file at link time.
Second point :
Use you or not libraries, a source file (.c) or (.cpp) is only compiled (and linked into the executable) once. That's the reason for having .h files that are included in other files and as such processed one time per including file
Third point :
The object is effectively instantiated once, since the .o file is linked only once

undefined reference to the shared library function

I have implemented a shared library in Linux and try to test it, but I get an error "undefined reference to `CEDD(char*)'".
I use Eclipse with following parameters:
Path to include files (here is
everything ok)
Path to the library
and its name. Path is correct and the
name is WISE_C (full name:
libWISE_C.so)
My Code:
Test programm I use for tests:
#include <iostream>
#include <Descriptor.h>
int main() {
char* path = "/export/home/pdmazubi3/workspace/proj1/src/pic.jpg";
double * cedd = CEDD(path); ///// <-ERROR!
std::cout << "!!!Hello World!!!" << cedd[1];
return 0;
}
Header Descriptor.h:
double* CEDD(char* path);
A part of Descriptor.c with desirable function:
#include "Descriptor.h"
#include "highgui.h"
#include "cv.h"
double* CEDD(char* path)
{
IplImage* srcImg;
IplImage* ImageGrid;
...
}
What I am doing wrog? I have raed a lot of articles in the Internet but I didn't found a solution.
undefined reference to `CEDD(char*)' is a compiler or linker error?
It's a linker error (although I don't think it usually includes the 'char*' bit), so it seems that it either cannot find your library or the library does not contain the function. The latter might also mean that it does contain the actual function, but with a different name; make sure both projects a compiled as C and not C++.
Edit: I missed that you program is C++ (which also explains the more detailed linker message). In this case you should add extern "C" (conditionally, so it is only used when using C++) to the declaration of CEDD if the library is in C.
Are you sure that you linked the object code generated for descriptor.c when building?