header-files

I don't want to write a .cpp file for every simple c++ class. when I write a class definition and declaration in a single .hpp file, the linker complains about multiple definition of member functions which are not implemented inside the body of the class. So I use templates to get rid of linker complaints: // log.hpp file template<typename T> class log_t { private: int m_cnt = 0; public: void log(); }; template<typename T> void log_t<T>::log() { std::cout << ++m_cnt << std::endl; } // some random type (int) typedef log_t<int> log; And then I can simply use log class in multiple .cpp files

Up until now I've managed to get Xcode to link to the Gnu Scientific Libraries (GSL) which I've installed under /usr/local/lib/ and with header files under /usr/local/include. Under "Build Phases" > "Link Binary With Libraries" I had added libgsl.a etc. Today, Xcode gives an error message claiming it can't find header files. For example #include <stdio.h> #include <gsl/gsl_matrix.h> int main(int argc, const char * argv[]) { printf("Hello, World!\n"); return 0; } results in 'gsl/gsl_matrix.h' file not found. I've tried to change the User Header Search path to no avail. Using gcc main.c -lgsl

I am porting some code to OpenBSD 5.0 and I ran into this very strange problem. My build settings use -isystem /usr/local/include . It is hard to remember but I believe I did that to avoid masses of compiler warnings from my use of -Wall on system types -- like BSD -- that install Boost to /usr/local/include . This seems to work great on FreeBSD. So take the following program: #include <boost/array.hpp> int main() { return 0; } Then build it with: c++ -O2 -pipe -isystem /usr/local/include -std=c++98 -o test test.cxx On OpenBSD I discovered that I get: In file included from /usr/include/g++

I've read a few of the articles about the need / applicability / practicality of keeping headers around in C++ but I can't seem to find anywhere a solid reason why / when the above should or should not be done. I'm aware that boost uses .hpp files to deliver template functions to end users without the need for an associated .cpp file, and this thought is partially sourced off browsing through that code. It seems like this would be a convenient way to deliver single file modules of say a new Wt or Qt widget (still sticking to the one class per .h convention). However are there any negative

I'm considering between header-only vs. header&source design. I'm not sure if the header&source allows compiler to optimize across object files and across linkage ? such as inlining optimization ? Header files and source files typically compiled as a single translation unit (since headers are included in the source files). So, that won't be an issue (unless you have a peculiar environment where headers are compiled separately). GCC does support optimizations across different translation units. See Link Time Optimization . See the -flto option's documentation for details: -flto[=n] This option

I've read up a bit on preprocessor directives and I've seen #import being used a few times in C programs. I'm not sure what the difference is between them, some sites have said that #include is only used for header files and #import is used more in Java and is deprecated in C. If that's the case, why do some programs still use #import and how exactly is it different from #include? Also, I've used #import in a few of my C programs and it seems to work fine and do the same thing as #include. This is well-explained in the Gnu CPP (C preprocessor) manual, although the behaviour is the same in