I have two cuda kernels imageFlow() and cornerDetect(), defined in their individual cu files. They share a common global function, convolute1D(), which should rightfully have been in its own cu file as well. I had to place it, the implementation - not just the definition of convolute1D, in a header file convolution.h. This is then included in both cornerDetect.cu and imageFlow.cu, in order to use it from both kernels. This is because everything must be in the "same compilation unit".
Now the problem is that after compilation, convolute1D is actually defined in both imageFlow.obj and in cornerDetect.obj, since the included header had the actual implementation of the function.
This means that the final linker stage conplains about convolute1D being defined multiple times.
One solution would be to always use namespaces, but this that THE solution? It seems more like patching up the problem. I still have the implementation for convolute1D multiple times in the final binary, and what if I have some reason to use the same namespace for both my imageFlow and cornerDetection?
What about use extern definition?
// convolution.h
extern "C" void convolution1D() {
...
}
// imageFlow.cu
extern "C" void convolution1d();
// call the function when you need
convolution1D();
Same approach for cornerDetect.cu file.
Related
I have a C++ method declared as follow:
std::tuple<std::vector<int>, std::size_t, std::size_t> get_state(); // Should I use a struct and expose the struct instead?
And I would like to declare a cython extension to interface it in Python
cdef extern from "cpp_sources/CClass.hpp":
cdef cppclass CClass nogil:
tuple[vector[int], size_t, size_t] get_state()
Unfortunately, I don't see an easy import to make to have access to a C++ tuple.
I also checked here with no success.
My question is, is there an easy way to have access to a c++ tuple? Or maybe there is a better way to have access to some elements?
(We don't care about performances for this exact method)
Unfortunately this is not supported. More generally variadic templates are not supported - that's why you have pair for example, but not a generic tuple.
In the github issue I linked they have their own version of a workaround, which is what I would come up with first - for every amount of N arguments I will actually use,
template<typename T_1, ... typename T_N>
using tupleN = std::tuple<T_1, ..., TN>;
and exporting each tupleN individually. There is no magic I'm aware of to make a general variadic template here.
Seems std::get is just used on tuple class. Why not make it member class of tuple in standard library, any other usages?
The reason get is a non-member function is that if this functionality
had been provided as a member function, code where the type depended
on a template parameter would have required using the template
keyword.
source.
Snippet code when get is non-member function:
template<class T>
void foo ( tuple<T>& t ) {
get<0>(t) = 10; // get is non-member function
}
and another if get is member function of tuple:
template<class T>
void foo ( tuple<T>& t ) {
t. template get<0>() = 10; // ugly
}
Which version of get usage do you prefer ? For me, the first is better.
There is also a much older, less c++11 specific and generally more general version of an answer. (If you are only wondering about the specific case, you don't need to read on).
The general case for free functions is described in this classic DrDobb's article by an absolute C++ guru.
The short n sweet version: If you separate between public interface with access to private members and public interface with access to only the public interface you have a harder separation between a class and operations on that class.
It looks somewhat ugly, decreases helpfulness of most IDEs, but has some profound effects on your code modularity, especially when you embrace the template frenzy of the last std iterations. Matthias's answer depicts one clear example of this.
A more classic advantage is, that you can provide a set of free functions inside an extra header that a user can include on demand. Now think about interoperation between templated but otherwise completely separate classes A and B. You can now tie them together by providing a header like A_B_interop.h, full of free functions, without switching paradigms. You include that header, the classes become more powerful.
What does the term 'namespace pollution' mean and why would making a method static help to prevent it?
This question seems to be similar but relates specifically to JavaScript, and the answers don't define the term.
A namespace is simply the space in which names exist (seems obvious enough now).
Let's say you have two pieces of code, one to handle linked lists, the other to handle trees. Now both of these pieces of code would benefit from a getNext() function, to assist in traversal of the data structure.
However, if they both define that function with the same name, you may have a clash. What will your compiler do when you enter the following code?
xyzzy = getNext (xyzzy);
In other words, which getNext() do you actually want to use? There are numerous ways to solve this, such as with object-oriented code, where you would use:
xyzzy = xyzzy.getNext();
and that would auto-magically select the correct one by virtue of the fact you've specified the type via the variable xyzzy itself.
But, even with mostly-OO code, there may be situations where you have a conflict, and that's where namespaces enter the picture. They allow you to place the names into their own area so as to distinguish them.
C++, as one example, places all its standard library stuff into the std namespace. If, for some reason, you need an fopen() or rand() function that works differently from the one in the library, you can place it in your own namespace to keep them separate.
Now that describes namespace clashes. Technically, namespace pollution is simply leaving your symbols in a namespace where they shouldn't really be. This doesn't necessarily lead to clashes but it makes it more likely.
The reason why making a method static (in C-like languages) has to do with the names being made available to the world outside the given translation unit (when linking, for example). With the code:
int get42 (void) { return 42; }
int main (void) { return get42(); }
both of those functions are made available to the linker.
Unless you have a need to call get42() from somewhere else, making it static:
static int get42 (void) { return 42; }
int main (void) { return get42(); }
will prevent it from polluting the namespace maintained by the linker – in C, applying the static qualifier to a file-level object or function gives it internal linkage.
It's similar to the C++ namespaces in that you can have a static int get42() in four hundred different source files and they won't interfere with each other.
Namespace pollution is a lot like pollution in general. It means that something is misplaced. In programming that means that code that should really live in separate namespaces is added to a common namespace (in some cases the global namespace). This can happen with both static and non static code, so I don't really see a scenario where static helps prevent namespace pollution.
Basically, namespaces' main function is to categorize code, and both static and non static code must be defined in a namespace somewhere.
I am trying to make a small interpreter using Flex and Bison.
Now I have two files: parser.l and parser.y. Usually, main function is put in parser.y file. What I want to do is to put the main function in a different file main.cpp which makes my package look neat.
#include "y.tab.h"
int main()
{
yyparse();
return 0;
}
But when I compile, I got an error:
undefined reference to `main'
So I know there is something wrong to include y.tab.h.
Could you someone to tell me how to do it?
Solution
I just figured it out:
add the following to your main.c file:
extern FILE *yyin;
extern FILE *yyout;
extern int yyparse(void);
SO noted:
I just figured it out: add the following to your main.c file:
extern FILE *yyin;
extern FILE *yyout;
extern int yyparse(void);
#Jonathan Leffler Noted
You don't really need yyin or yyout since you don't (yet) reference
them from the file containing main(). However, if you end up doing
work such as reading from files specified on the command line instead
of standard input, you may need them. It would be nice if Bison
generated a header with the appropriate declarations in it. The
y.tab.h file is not, however, the place for that information; it is
used to convey information between the parser and the lexical
analyzer, not between the application and the parser.
I see the terms "declaration," "prototype" and "symbol" thrown around interchangeably a lot when it comes to code like the following:
void MyUndefinedFunction();
The same goes for "definition" and "implementation" for things like this:
void MyClass::MyMethod()
{
// Actual code here.
}
Are there any distinctions between the terms, as with "argument" and "parameter?" Or are they truly synonymous?
Note: I'm not sure if this belongs here or on Programmers, so I posted it on both sites. If anyone has any objections, let me know and I'll delete one.
Unless you run into a purist, they are generally interchangable, except for symbol and prototype (difficult to give absolutes on language-agnostic)
symbol generally refers to a hook point for linking 2 bits of code together, such as a library entry point, or a target for resolving static linking
prototype generally refers to a definition of what a function/method looks like (arguments, return type, name, various types of visibility), but doesn't include an implementation.
You missed function vs. method, but my definition is:
function a callable bit of code that isn't bound to an object
method a callable bit of code in an object's namespace. Generally implemented by the compiler as a function that takes the object instance as it's first argument.
Possibly parameter hints at limiting scope, and therefore read-only.
Note If you ask a purist, you're more likely to have an argument than a parameter.
The difference between declaration and prototype is mainly in C, where the following is a non-prototype declaration:
int foo();
Note that this is different from:
int foo(void);
The latter is a prototype for a function taking no arguments, while the former is a declaration for a function whose argument types are not specified in the declaration. This can actually be useful to avoid function-pointer-type casts with certain uses of function pointers, but it's very easy to mess up, and messing it up invokes undefined behavior. Many C programmers consider non-prototype declarations harmful, and gcc has a warning option to flag them.