I want to write library for avr which uses <util/delay.h> and it requires F_CPU to be defined, so i faced the problem, is there any way in C/C++ for libraries to get defines for attributes which user writes in main file? I guess the question is kinda dumb, since libraries compiles first, then the main file. I've come to a solution with using init.h file, which contains user initial setups, still doesn't solve the problem with already compiled libraries. Still, maybe there are some other workarounds or standardized approach for this type of problem. here's the code:
main.cpp
#include "myLib.h"
#include <avr/io.h>
#include <util/delay.h>
int main(){
DDRD = 0xFF;
PORTD = 0;
while (1)
{
blink();
}
return 0;
}
init.h
#pragma once
#define F_CPU 16000000UL
myLib.h
#pragma once
#include "init.h"
#include <avr/io.h>
#include <util/delay.h>
void blink();
myLib.cpp
#include "myLib.h"
void blink(){
PORTD ^= 0xFF;
_delay_ms(500);
}
In your Makefile add -DF_CPU=16000000UL to the C_FLAGS.
Adding -DF_CPU to C_FLAGS is how this is commonly done.
Related
I am a beginner to cuda, c++ and I am trying to move openssl sha1 cpu code to cuda c,but I ran into a weired problem.
here is the minimum code that can reproduce the problem.
There are three files in this vs2015 cuda9.0 project. They are main.cpp ,sha1.cu and sha1.h
//main.cpp
#include "cuda_runtime.h"
#include "device_launch_parameters.h"
#include "openssl\sha.h"
int main()
{
SHA_CTX ctx;
SHA1_Init(&ctx);
return 0;
}
//sha1.h
#ifndef SHA1_H
#define SHA1_H
#include <stdint.h>
#include <cuda_runtime.h>
namespace cudatest {
#ifdef __cplusplus
extern "C" {
#endif
typedef struct
{
uint32_t state[5];
uint32_t count[2];
unsigned char buffer[64];
} SHA1_CTX;
#define SHA_CTX SHA1_CTX
#define SHA_DIGEST_LENGTH 20
__device__ void SHA1_Init(SHA1_CTX * context);
#ifdef __cplusplus
}
#endif
}
#endif /* SHA1_H */
//sha1.cu
#include <cuda_runtime.h>
#include "sha1.h"
namespace cudatest {
__device__ void SHA1_Init(SHA1_CTX * context)
{
}
}
The main.cpp uses C/C++ compiler and sha1.cu uses CUDA C/C++
And I add openssl headers into the AdditionalIncludeDirectories,set directory which contains ssleay32.lib and libeay32.lib to library path,set AdditionalDependencies with ssleay32.lib, libeay32.lib .
Then the project built with no error and no warning. But when I run it
or debug it,I found the function SHA1_Init runs into device code and
the program crashed immediately.
why the compiler linked function SHA1_Init with the cuda device
SHA1_Init implement which has a namespace cudatest wrapped instead
of a ssleay32.lib, libeay32.lib CPU implement?
OK,I found the problem.I shouldn't use extern "C" in a c++ namespace.It make the function visiable to the global namespace. if you define another c SHA1_Init function in a .cpp file ,the linker will complain.But if another SHA1_Init is in a openssl lib,the vs C/C++ linker warnned nothing but linked to the cuda implement.
Below is a minimal example to use the great Boost.Serialization library.
To compile the library I need to link with the boost_serialization precompiled library.
$ c++ -std=c++11 example.cpp -o example.x -lboost_serialization
^^^^^^^^^^^^^^^^^^^^^
The library is heavily templated an although complicated internally the actual code (function body) is quite simple. There are only a few references that need the linking, namely:
boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::text_oarchive_impl(std::ostream&, unsigned int)
boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::text_iarchive_impl(std::istream&, unsigned int)
boost::archive::text_iarchive_impl<boost::archive::text_oarchive>::~text_oarchive_impl()
boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::~text_iarchive_impl()
...
boost::archive::archive_exception::~archive_exception()'
Is there a chance that the library can be used without linking as a header-only library?
For example some undocumented trick or hack?
That would make it more simple to use in some supercomputer clusters and environments where it is not that simply to compile Boost.
#include<sstream>
#include<numeric>
#include<boost/archive/text_oarchive.hpp> // needs linking
#include<boost/archive/text_iarchive.hpp>
#include<boost/serialization/vector.hpp>
int main(){
std::vector<double> v(10); std::iota(v.begin(), v.end(), 0);
std::stringstream ss;
{
boost::archive::text_oarchive toa(ss);
toa << v;
}
std::vector<double> v2;
boost::archive::text_iarchive tia(ss);
tia >> v2;
assert(v == v2);
}
EDIT: I would be very cool if the library gave the option to be header only, like Boost.Asio does (https://stackoverflow.com/a/40729439/225186.)
EDIT2: The author and maintainer of Boost.Serialization rejected the idea of making it header only. https://github.com/boostorg/serialization/issues/71
I ended up including the cpp sources from a certain version of Boost Serialization.
I chose the cpp files by trial and error.
https://gitlab.com/correaa/boost-mpi3/-/tree/master/include/mpi3/serialization_hack
Basically, I include these cpp files from the same place I would include the Serialization hpp files.
#include <boost/archive/detail/common_iarchive.hpp>
#include <boost/archive/detail/common_oarchive.hpp>
#include <boost/archive/archive_exception.hpp>
#include <boost/archive/basic_streambuf_locale_saver.hpp>
#include <boost/archive/detail/auto_link_archive.hpp>
//#include <boost/archive/detail/abi_prefix.hpp> // must be the last header
#include <boost/serialization/array.hpp>
#include <boost/serialization/is_bitwise_serializable.hpp>
#include <boost/serialization/item_version_type.hpp>
#include <boost/serialization/string.hpp>
#include <boost/mpl/placeholders.hpp>
#include <any>
#include <optional>
// use this to avoid need for linking -lserialization
#ifdef _MAKE_BOOST_SERIALIZATION_HEADER_ONLY
//#include <boost/archive/detail/decl.hpp>
#if BOOST_VERSION > 106000 && BOOST_VERSION < 106600
#include "../mpi3/serialization_hack/singleton.cpp"
#endif
#if BOOST_VERSION < 105900
#define BOOST_ARCHIVE_DECL
#define BOOST_SERIALIZATION_DECL
#endif
// NOLINTBEGIN(hicpp-use-auto,modernize-use-auto) external code
#include "../mpi3/serialization_hack/archive_exception.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/basic_archive.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/basic_iarchive.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/basic_iserializer.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/basic_oarchive.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/basic_oserializer.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/extended_type_info.cpp" // NOLINT(bugprone-suspicious-include) hack
#include "../mpi3/serialization_hack/extended_type_info_typeid.cpp" // NOLINT(bugprone-suspicious-include) hack
// NOLINTEND(hicpp-use-auto,modernize-use-auto)
A problem with this approach is that I had to modify the sources to accommodate different versions of Boost.Serialization and also had to do some modification to appease compiler warnings and static analyzers.
I'm working with the boost libraries and opencv, and now I have to implement my own headers and source code (additional to main.cpp) that requires the libraries as well.
The main.cpp looks like (just in principle):
// STL includes
#include <stdlib.h>
...(some other STL stuff)
// Boost includes
#include <boost/array.hpp>
...(a lot of other boost stuff)
//OpenCV
#include <opencv2/opencv.hpp>
// Own header files
#include <myHeader.hpp>
main() do_some_stuff;
This works, if I don't have anything related to boost in myStuff.hpp. But if I add something in it (the function descriptions are in myStuff.cpp), like:
class aClass{
public:
aClass(int);
void doSomething(boost::shared_ptr<int>);
void doSomethingElse(cv::Mat);
};
then it says 'boost' had not been declared, or 'cv' does not name a type.
I was like, ok, I just need to include the headers in this file as well, so I added the same includes, but then when it tries to link it gives a lot of errors like:
/usr/include/boost/operators.hpp:308:35: error: expected identifier before numeric constant
/usr/include/boost/operators.hpp:308:35: error: expected ‘>’ before numeric constant
/usr/include/boost/operators.hpp:310:1: error: expected class-name before ‘{’ token
/usr/include/boost/operators.hpp:311:3: error: expected unqualified-id before numeric constant
...(a lot more of these errors)
I'm using a Makefile to build this project, that looks like:
OPENCV_I = `pkg-config --cflags opencv`
#it finds boost without any additional -I or -L options...
INCLUDEPATHS = $(OPENCV_I)\
-I.\
-L.
LIBS=-lGL -lGLU -lm -lboost_program_options -lboost_system -lboost_thread -pthread -lrt -lopencv_core -lopencv_highgui
SRCCXX := main.cpp myStuff.cpp
OBJSCXX := $(SRCCXX:%.cpp=${BUILDDIR}/%.o)
$(BUILDDIR)/%.o : %.cpp
$(CXX) $(CXXFLAGS) $(INCLUDEPATHS) -c $< -o $# -DdDOUBLE $(LIBS)
all: ${OBJSCXX}
$(CXX) $(LDFLAGS) $(INCLUDEPATHS) -o $(OUTNAME) $? -DdDOUBLE $(LIBS)
Previously I was using CMake, and it worked quite well with these kind of projects, just this one is a part of a bigger project where they use Makefiles for everything. So I guess the main problem is with the makefile, probably when I list my source codes SRCCXX := main.cpp Visualisation.cpp it doesn't like it...
Any suggestions?
Thank you in advance.
EDIT....................................
So my whole myStuff.hpp looks like:
#define _USE_MATH_DEFINES
#include <math.h>
#define RINGS 5
#define SECTIONS 12
// Boost includes
#include <boost/array.hpp>
#include <boost/asio.hpp>
#include <boost/assign/ptr_list_of.hpp>
#include <boost/assign.hpp>
#include <boost/bind.hpp>
#include <boost/date_time.hpp>
#include <boost/foreach.hpp>
#include <boost/function.hpp>
#include <boost/make_shared.hpp>
#include <boost/math/constants/constants.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/condition_variable.hpp>
#include <boost/program_options.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <opencv2/opencv.hpp>
class Sensor{
public:
Sensor(int);
void Update(boost::shared_ptr<char[RINGS][SECTIONS]>);
int Id();
private:
char data[RINGS][SECTIONS];
int id;
};
and the myStuff.cpp:
#include "myStuff.hpp"
void Sensor::Update(boost::shared_ptr< char[RINGS][SECTIONS] > buffer){
for(int i=0;i<RINGS;i++) for(int j=0;j<SECTIONS;j++) data[i][j]=buffer[i][j];
};
Sensor::Sensor(int a){
id=0;
};
int Sensor::Id(){
return id;
};
and my main.cpp:
// STL includes
#include <stdlib.h>
#include <iostream>
#include <mutex>
#include <string.h>
#include <typeinfo>
#include <queue>
#include <memory>
// Boost includes
#include <boost/array.hpp>
#include <boost/asio.hpp>
#include <boost/assign/ptr_list_of.hpp>
#include <boost/assign.hpp>
#include <boost/bind.hpp>
#include <boost/date_time.hpp>
#include <boost/foreach.hpp>
#include <boost/function.hpp>
#include <boost/make_shared.hpp>
#include <boost/math/constants/constants.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/condition_variable.hpp>
#include <boost/program_options.hpp>
#include <boost/numeric/ublas/matrix.hpp>
//OpenCV
#include <opencv2/opencv.hpp>
// Own header files
#include "myStuff.hpp"
////////////////////////////////////////// Main
int main (int argc, char **argv)
{
Sensor sensor(0);
return 0;
}
Well first things first... when including your own headers from within your project I would recommend that you use "mine.hpp" instead of <mine.hpp>. This ensures that the compiler won't search the complete include path and accidentally find some other include of the same name (different version for example).
Second, when you have a dependency within a class then you include the header for that dependency within that class. You cannot make assumptions that someone will include all your dependencies in a main class or some other class. Sometimes someone will just want to use your class by itself. You don't want them to then have to figure out your dependencies. Don't worry about replication either as the include guard (or pragma) will prevent that.
As for your particular problems you will need to give use your code. You have certainly managed to correctly include your headers at that point. I would guess that they might stem from a missing { or ; somewhere. Look at your very first error and solve that one.
EDIT
The issue appears to be with how you are using boost. I had a look at what in operators.hpp and in version 1_44 what I see is a struct definition with 4 template parameters, one of which is defaulted to boost::detail::empty_base<T>. Only thing I can say is to make sure that you have your entire boost library on your include path, and link path.
EDIT2
From your newly posted code I see a couple of problems. First is that you have WAY too many includes in your header. You should only ever have class dependency includes in your header, and always prefer to put your header files into your implementation (.cpp) file. This helps to prevent extremely long compilation times. So first modify your header to include only the dependencies you need:
#include <boost/shared_ptr.hpp>
#define RINGS 5
#define SECTIONS 12
class Sensor{
public:
Sensor(int);
void Update(boost::shared_ptr<char[RINGS][SECTIONS]>);
int Id();
private:
char data[RINGS][SECTIONS];
int id;
};
Then in your implementation the only change is to put braces around your for loops (this is for clarity and safety... understand why you put it on one line but it is not worth it). Also put your CTOR first:
#include "myStuff.hpp"
Sensor::Sensor(int a){
id=0;
};
void Sensor::Update(boost::shared_ptr< char[RINGS][SECTIONS] > buffer){
for(int i=0;i<RINGS;i++) {
for(int j=0;j<SECTIONS;j++) {
data[i][j]=buffer[i][j];
}
}
};
int Sensor::Id(){
return id;
};
Main
#include "myStuff.hpp"
int main (int argc, char **argv)
{
Sensor sensor(0);
return 0;
}
The ONLY dependency you need is boost::shared_ptr. To be honest though, I'm pretty sure you don't need that either. Anyway I would recommend that you start with the above and then build up by adding one dependency at a time.
After a couple of hours I figured it out. myStuff.cpp also requires the header inclusion. Silly mistake, but still why can't the compiler says something like non defined or can't find instead of a couple of pages of messed up errors...?
Thanks anyway for your help.
I am trying to implement a test project using the Point Cloud Library and OpenCV with multiple files. When I try to compile, I get the "already defined error" message. Probably I'm doing something stupid that cannot realize for some reason - I tried out a couple of solutions found here, none of them seemed to be help in my case.
What I have:
A libs.h file, where I load the lib files (in Project properties, I only set up the .lib paths and load the libs "by hand", like the headers):
#pragma once
#ifndef PCLTEST_LIBS
#define PCLTEST_LIBS
#ifdef _DEBUG
#pragma comment(lib, "pcl_apps-gd.lib")
#pragma comment(lib, "pcl_common-gd.lib")
// a bunch of other debug libs
#else
// the release libs
#endif
#endif
A main file from which I basically deleted everything at this point to debug:
// load the libs
#ifndef PCLTEST_LIBS
#include "libs.h"
#endif
// pcltest includes
// if only this first one is #included, everything is OK
#include "opencvOperations.h"
// #including this one causes the error
#include "files.h"
// these ones are not working also
//#include "cloudOperations.h"
//#include "visualize.h"
// c++ headers
#include <stdio.h>
#include <string>
//#include <sstream>
//#include <iostream>
void writeInfo()
{
// some std::cout calls
}
int main( int argc, char* argv[] )
{
writeInfo();
// this function is in opencvOperations.h and works OK
pcltest::openLena();
}
Then I get several error messages in my main.obj that some (PCL related) symbols are already defined in files.obj. I use PCL related calls both in opencvOperations and files, the first one is OK, the second one does not work.
Edit:
To add more detail, my files.h header:
#pragma once
#ifndef PCLTEST_FILES
#define PCLTEST_FILES
// pcl headers
#ifndef PCL_COMMON_H_
#include <pcl/common/common_headers.h>
#endif
#ifndef PCL_IO_FILE_IO_H_
#include <pcl/io/file_io.h>
#endif
#ifndef PCL_IO_PCD_IO_H_
#include <pcl/io/pcd_io.h>
#endif
#ifndef PCL_IO_PLY_IO_H_
#include <pcl/io/ply_io.h>
#endif
// boost headers
#ifndef BOOST_FILESYSTEM_OPERATIONSX_HPP
#include <boost/filesystem/operations.hpp>
#endif
#endif
namespace pcltest
{
// function to open PCL or binary PLY files
pcl::PointCloud<pcl::PointXYZ>::Ptr openCloud(std::string filename);
// function to save the point cloud to PCD format
void saveCloud();
}
Before splitting the code into separate files, everything worked well (with the same project settings).
Edit2:
I located the source of the problem,
#include <pcl/io/ply_io.h>
causes this. For now, I got rid of everything related to PLY and everything works fine. I'll look at it later, this might be a PCL library specific issue. Still strange to me why this call causes linker error in an other file, where I don't even use PLY related functions/variables.
I had the same problem as you had. I had a surface.h and surface.cpp file, and I found out that I had to include the ply_io.h file from surface.cpp rather than surface.h and now it compiles fine. I hope that helps or makes sense! haha
If a constant is being instantiated in an include one can also use selectany, per http://msdn.microsoft.com/en-us/library/5tkz6s71%28v=vs.80%29.aspx -- in my case:
const int CSdata[] = {1, 2, 3, 4};
when included in more than one source part produces LNK2005 at link time, avoided via:
const __declspec(selectany) int CSdata[] = {1, 2, 3, 4};
Non-portable, yeah ...
Why use precompiled headers?
Reading the responses, I suspect what I've been doing with them is kind of stupid:
#pragma once
// Defines used for production versions
#ifndef PRODUCTION
#define eMsg(x) (x) // Show error messages
#define eAsciiMsg(x) (x)
#else
#define eMsg(x) (L"") // Don't show error messages
#define eAsciiMsg(x) ("")
#endif // PRODUCTION
#include "targetver.h"
#include "version.h"
// Enable "unsafe", but much faster string functions
#define _CRT_SECURE_NO_WARNINGS
#define _SCL_SECURE_NO_WARNINGS
// Standard includes
#include <stdio.h>
#include <tchar.h>
#include <iostream>
#include <direct.h>
#include <cstring>
#ifdef _DEBUG
#include <cstdlib>
#endif
// Standard Template Library
#include <bitset>
#include <vector>
#include <list>
#include <algorithm>
#include <iterator>
#include <string>
#include <numeric>
// Boost libraries
#include <boost/algorithm/string.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/scoped_array.hpp>
//Windows includes
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include "FILETIME_Comparisons.h"
#include <shlwapi.h>
#include <Shellapi.h>
#include <psapi.h>
#include <imagehlp.h>
#include <mscat.h>
#include <Softpub.h>
#include <sfc.h>
#pragma comment(lib, "wintrust.lib")
#pragma comment(lib,"kernel32.lib")
#pragma comment(lib,"Psapi.lib")
#pragma comment(lib,"shlwapi.lib")
#pragma comment(lib,"imagehlp.lib")
#pragma comment(lib,"Advapi32.lib")
#pragma comment(lib,"Shell32.lib")
#pragma comment(lib,"Sfc.lib")
#pragma comment(lib,"Version.lib")
// Crypto ++ libraries
#ifdef _DEBUG
#pragma comment(lib,"cryptlibd.lib")
#else
#pragma comment(lib,"cryptlib.lib")
#endif
#define CRYPTOPP_ENABLE_NAMESPACE_WEAK 1
#include <md5.h>
#include <sha.h>
// String libraries
#include "stringUnicodeConversions.h"
#include "expandEnvStrings.h"
#include "randomString.h"
#include "getShortPathName.h"
// Regular Expression Libraries
#include "fpattern.h"
// File Result Record
#include "unixTimeToFileTime.h"
#include "fileData.h"
// Writer
#include "writeFileData.h"
// Criteria Structure System
#include "priorities.h"
#include "criterion.H"
#include "OPSTRUCT.H"
#include "regexClass.H"
#include "FILTER.h"
// Sub Programs Root Class
#include "subProgramClass.h"
// Global data
#include "globalOptions.h"
// Logger
#include "logger.h"
// Console parser
#include "consoleParser.h"
// Timeout handler
#include "timeoutThread.h"
// Zip library
#include "zip.h"
#include "unzip.h"
#include "zipIt.h"
// Scanner
#include "mainScanner.h"
#include "filesScanner.h"
// Sub Programs
#include "volumeEnumerate.h"
#include "clsidCompressor.h"
#include "times.h"
#include "exec.h"
#include "uZip.h"
// 64 bit support
#include "disable64.h"
In C/C++, the #include mechanism is a textual copy of the file specified into the current file. Headers include other headers (which include yet other headers), so when you do a #include, it could be adding tens of thousands of lines of C++ into each cpp file (or cxx, c, whatever), all of which need to be compiled each time. This can be a severe bottleneck for large projects.
Precompiled headers speed this up by compiling each header once, then including that compiled state into the cpp they are included in.
It compiles a lot quicker. C++ compilation takes years without them. Try comparing some time in a large project!
Re: your current usage, if you have a target with a very large number of files, it may still be faster to use PCH in that way - try switching them off to find out. It depends: if you have a lot of headers of your own, and you change them only infrequently, and you have a very large number of source files that you change much more frequently, then your PCH usage will cut rebuild times.
But normal advice is to only put things in PCH that never change, because there is a certain overhead to producing the PCH itself. If you trigger that off with every rebuild (by constantly tweaking one of your headers), using PCH may make the rebuild slower.
So you don't have to compile them every time you build your project. They're used for system headers that aren't going to change.
It speeds up compilation.
When you're including headers from other projects, you don't expect to change them. If you put these into a precompiled header, then that code will not have to be recompiled when you make changes to your source code. This reduces repetitive compilation of unchanged code, speeding up compile time.