To make available some useful function in CINT (C++ interpreter of ROOT), I configured my rootrc config file to execute a rootlogon.C file each time I run root to launch the interpreter.
In rootlogon.C, this piece of code is present:
{
gROOT->ProcessLine("#include \"GenericToolbox.h\"");
}
This line is kind of working as intented since I'm then able to access most of the defined function in the header file. However the functions involving template can't be accessed. I understand that because this is a header-only library, the interpreter can't predict which object types will be used as template definition.
So do you know if I could make a kind of shared library that could be loaded in the rootlogon, which would define specific template functions?
I've seen some examples suggesting to utilize a LinkDef.h file which contains #pragma link C++ function lines to specialize templates, but I don't understand how to use it...
Any idea?
Related
I am trying to write my first (very) small, for now only self-use, library. In the process I came across questions regarding how I should separate my headers/source code/object files in a logical way.
To be more specific, I'm writing a small templated container class, so for one I have to include the implementation of this class inside its header.
I have a directory structure like this:
include/ - "public" .hh header files included by extern projects
src/ - .cc files for implementation (+ "private" .hh header files?)
lib/ - .o compiled library files linked by extern projects
I am already not sure if this makes sense.. in my case I also wrote some helper-classes used by my templated container class, one of which is something like an iterator. So I have the following files:
container.hh
container.cc
container_helper.hh
container_helper.cc
container_iterator.cc
container_iterator.hh
While I want to have access to their functions in external projects (e.g. incrementing the iterator), it makes no sense to me that a project would specifically
#include "container_iterator.hh"
Now, since I want projects to be able to use the container class, I put "container.hh" and "container.cc" (since it must be included in "container.hh" because of the template) into the "include/" directory, which is then included by other projects.
Now my confusion arises.. the container class needs access to the helper classes, but I don't want other projects to only include the helper classes, so it seems wrong to place also the helper classes into "include/" directory. Instead, I would place them in "src/".
But if I do this, then to include these in "include/container.cc" I have to use relative filepath
#include "../src/container_iterator.hh"
But now if I "distribute" my library to an external project, i.e. I only make the "include/" directory visible to the compiler, it will not compile (?), since "../src/container_iterator.hh" does not exist.
Or do I compile the container class and put it as library into "lib/", which is then linked by other projects? But even then do I not still need to include the header "container.hh", to be able to find the function declarations, which leads to the same problem?
Basically I'm lost here.. how does the standard do this? E.g. I can
#include <vector>
, but I don't know of any header to only include std::vector::iterator, which would make no sense to do so.
At some point in my expanation I must be talking nonsense but I cannot find where. I think I understand what a header and a library is/should be, but when it comes to how to design and/or "distribute" them for an actual project, I am stuck. I keep coming across problems like this even when I started learning C++ (or any language for that matter), no course / no book ever seems to explain how to implement all these concepts, only how to use them when they already exist..
Edit
To clarify my confusion (?) more.. (this got a bit too long for a comment) I did read before to put implementation of templated classes into the header, which is why I realized I need to at least put the "container.cc" into the include/ dir. While I don't particularly like this, at least it should be clear to an external user to not include ".cc" files.
Should I take this also as meaning that it never makes sense to compile templated classes into a library, since all of it will be always included?
(So templated code is always open-source? ..that sounds wrong?)
And in this case I still wonder how STL does it, does vector declare & define its iterator in its own header? Or is there a separate header for vector::iterator I could include, it just would make no sense to do so?
Hopefully I explained my intent clearly, please comment if not.
Thanks for any help!
In my experience, the most common method to handle your problems is to have headers with the template declarations and documentation (your .hh files), which also include .inc or .tcc (your preference) files with the template definitions. I also suggest keeping all files that may be included by external projects in the same folder, but if you want to keep things clean, put your .inc/.tcc files in a folder within include called detail (or bits if you like GNU style).
Putting stuff in a detail folder,
and using a weird extension should deter users enough.
To answer your other questions:
Due to the nature of C++ templates,
either the entire source of the parts of a template you use
must be present in the translation unit (ie. #include'd),
or you can use explicit instantiation
for a finite number of arguments
(this is not generally useful for a container, though).
So, for most purposes, you have to distribute a template's source, though,
of course, (as mentioned in the comments) "open source" is about licence,
not source visibility.
As for the standard libraries, lets use <vector> as an example.
The GNU C++ Library has a vector file that (among other things) includes
bits/stl_vector.h which has the declarations & documentation,
and includes a bits/vector.tcc that has the definitions.
LLVM's libc++ just has one giant file,
but puts the declarations at the top (without documentation!)
and all the definitions at the bottom.
As a final note, there are lots of open source C++ libraries that you can take a look at for inspiration in the future!
I'm working on a logging mechanism for a project, and currently each API function needs to add
start_api_call(***)
in the beginning of the function
where *** for the function do_something(int foo, int bar) is "foo", foo, "bar",bar
(The log function takes the parameters and form the desired message)
I would like to make this line auto-generated, where the vision is that somehow (mabye clang tools?) the compiler checks for each function in a .cpp if it is an API function (more details later) and if it is, just add the start_api_call(***) to the code.
I have 2 major problems regarding which direction should i go
1) I have never wrote code that it's 'goal' is to parse a source code, hence i don't know which direction should i head, I've read some documentation about the clang tools, but maybe just a python script would be better here?
2) Our design is as follows:
object_foo.h //inside .include/
class foo{
API functions
}
object_foo_impl.h //inside .src/
include "object_foo.h"
class foo_impl :foo{
foo API functions
a lot more functions
}
object_foo_impl.cpp
include "object_foo_impl.h"
{
implementation of all foo_impl functions
}
The start_api_call should be inserted only for the API functions,
thus i need to find a way to query inside the .cpp file, if this function came from the foo.h, or from the foo_impl.h file.
I have a somehow working concept of how to do it using python scripts, that parse all of our source code, identifying using regex which text inside a /include/.h file is a function and then finding all the functions inside .cpp files that implement those functions,
but (if possible) the concept of adding a rule in the compilation(/preprocessor) time is much more attractive.
Any help would be very much appreciated.
I have declared some global variables to be _Cilk_shared. They are used in the functions that I want to offload They are used in some functions I do not want to be offloaded as well.
So initially I only declared those functions that I need to offload as _Cilk_shared and call those function using _Cilk_offload.
It compiles fine. And when I run it on host only it gives correct result.
Then I run it with MIC. it gives me runtime error about can not load library blablabla undefined symbol followed by function names that I did not declare as _cilk_shared. Those functions are not needed to be _cilk_shared as well.
So I have to change those functions to _cilk_shared. Run it again. This time MIC gives correct result.
And I checked whether those functions (which I did not want to offload and did not declare as _cilk_shared initially ) are offloaded or not, by Using
#ifdef __MIC__
printf(" Running on MIC\n");
#else
printf("No MIC\n");
#endif
The result is that they are not offloaded....
So I am wondering why it wants me to declare those functions as _Cilk_shared?
When a function is declared for offloading -
if the function is defined in that file, the compiler generates
object code that will run on the processor and object code that will
run on the coprocessor.
if the function is used in that file, it
generates object code that will call the processor version and code
that will call the coprocessor version (unless the call is inside an
area that is protected by '"ifdef MIC"
So why might the loader want a function to have been declared for offload even if you never call it in an offloaded region?
Well if the function is part of a class, then the entire class needs to be declared for offload because the class 'knows' what functions are part of it. When you load the object code for a class, you load in the whole class. In this case if you are going to share objects of that class, it should be declared as _Cilk_shared.
You can get into similar problems if the functions are in a dynamically linked library. The dynamically linked library 'knows' what functions are part of it and it 'knows' what functions are required by it. So, when you run your code, the loader wants to find all the files the library 'knows' it needs. In this case, the simplest thing is to just make offloaded versions of all the libraries. Other things you can try - try either statically linking the library containing those files or try creating libraries that don't 'know' they need things they really don't - break your library into pieces or try explicitly create separate host and coprocessor version of the library as you would for code you are going to run natively on the coprocessor.
If this doesn't explain what you are seeing, let me know.
I just started on a few C++ tutorials, and I have run into something that I just can't seem to make much sense of.
In C++ it seems people are using a code file and a header file, for me this just seem inconvinient. Why would I want to swap around between two files just to write a simple getter method.
Is it considered the "correct" way to use headers in C++? Or is it just the tutorial I have picked up that uses this?
I get the idea of splitting code to make it look more clean, but is it good for anything else other than that?
Thanks in advance.
There are some reasons for using hpp(header)- and cpp(code)-files. One of them is the following: A library (dll- or so-file) cannot be "used" like a jar-file in java. If you write a library, you have to provide declarations of the classes, methos,... in form of a hpp-file.
Think about using the class you wrote in other files. If you had the class definition in a separate file, you could help the compiler to figure out how to use the class by including the header file in places where you are planning to use this code.
The compiler only needs to know whether you are using the classes right(it does not care about how to run it, until linking), therefore all you need to give the compiler is the declaration of the class(header file), to do the error checking. When you say "include", the preprocessor just copies and pastes the header file contents into the new file, so that the new file now knows how to use the class you wrote.
A header file in c++ stores alot of information, if c++ have been made using every single "header" file in c++ in each program you make, when you then write a function from iostream for example, the program will go through every single header file just to find the right header file. so instead they made the #inlcude function in c++, so you could specify where your functions are from.
And when you create a program you could make own header files, so the code is more nicely set up. and then instead of having to make alot of lines of code in one main source file, you could import others. like if you are making a game, one header file for Animals and in that header file you have a Class for Cats, and one for dogs. having a more clean code.
In C/C++, headers are used to share the class structure (among other things) between classes.
so one can use
include "classFOO.h"
in classBAR.h (or classBAR.cpp) and use classFOO.
(1). When using C++ template, is it correct that the compiler (e.g. g++) will not compile the template definition (which can only be in header file not source file) directly, but generate the code based on template definition for each of its instantiations and then compile the generated code for its instantiations?
(2). If I want to write a C++ library which provide template classes and template functions, is it impossible to compile the library into shared file (.so, .a) because their instantiations will not be anywhere in the code of the library but only appear in the user's program? If yes, does it mean that template libraries are just source code files not precompiled files?
How is C++ standard template library (STL) implemented? Is its source code precompiled or compiled together with user's program?
(3). In C,
how to write a library that provide functions acting like template functions in C++? Is overloading a good solution?
If I have to write a procedure into a different function for different types of arguments, is there a good way for code reusing? Is this a good way to do it http://www.vlfeat.org/api/imop_8c_source.html? Any other ways?
Thanks and regards!
When using C++ template, is it correct that the compiler (e.g. g++)
will not compile the template
definition.
Yes. It's a correct assumption.
A template definition is incomplete code. You need to fill in the template parameters before compiling it.
If I want to write a C++ library which provide template classes and
template functions, is it impossible
to compile the library into shared
file (.so, .a)
No it's not possible. You can only compile individual instantiations of a template.
How is C++ standard template library
(STL) implemented? Is its source code
precompiled or compiled together with
user's program?
A large part of the STL code resides in header files and gets compiled together with your application.
In C, how to write a library that
provide functions acting like template
functions in C++? Is this a good way
to do it
http://www.vlfeat.org/api/imop_8c_source.html?
Any other ways?
Including the same file multiple times after redefining a macro (as demonstrated in the link you provided) is a good way to do this.
(3). In C, how to write a library that provide functions acting like template functions in C++? Is overloading a good solution?
If I have to write a procedure into a different function for different types of arguments, is there a good way for code reusing? Is this a good way to do it http://www.vlfeat.org/api/imop_8c_source.html? Any other ways?
When I need to write general purpose code I use void * as basic data type. This is good because it allows you to store both a generic pointer and a "primitive" value (like a int). Also recently I had to compile some code using this pattern in a 64 bit environment, and this taught me the importance of the stdint.h data types!
Speaking of acting like template in C, this is not a good idea. This is just my opinion, of course, but I think that the strong point of C is its simplicity, which is the reason why C is less error prone than C++.