CUDA 5.0 Header Files - c++

I am struggling with someone's terribly written project and I'm trying to get it compiled ASAP... (best approach would be to do this correctly but time is an issue) ... anyways, they seem to have written this with an older API, where #include <cuda.h> gave you access to the api functions.
It seems the API functions have been moved to other headers and #include <cuda.h> is no longer enough. What should I do:
Include cuda_runtime_api.h and other header files
Compile this cpp (no kernel function calls) with nvcc?
TIA

for example:
#include <cstdlib>
#include <stdio.h>
// includes CUDA Runtime
#include <cuda_runtime.h>
// maybe you need also helpers
#include <helper_cuda.h>
#include <helper_functions.h> // helper utility functions
you need to add
/usr/local/cuda-5.0/bin/nvcc
as C++ Compiler -> Tool also. works with g++ 4.4
in your .cu file you need then #include <curand_kernel.h> if you are using CURAND library
as Robert Crovella said:
You should not need to explicitly include cuda.h if you are only using
the cuda runtime API to access CUDA functionality. If you are using
the driver API, things are different.

Related

Needing to link to some c++ standard library headers from rust

I am building an FFI crate (the sys crate part specifically), and for the most part it's a c library with a single cpp file in it. Looks like it's some sort of vendor file.
svm.cpp links to the following standard library headers
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <float.h>
#include <string.h>
#include <stdarg.h>
#include <limits.h>
#include <locale.h>
#include <thread>
#include <fstream>
#include <sstream>
#include <vector>
Strangely, this cpp file doesn't seem to link to the c++ standard libraries that it depends on, so I had to do it through the rust build system.
previously I was able to get this working by adding the following line to my build.rs
println!("cargo:rustc-flags=-l dylib=stdc++");
This works on linux using the gnu toolchain, but i'm trying to get this to work on windows using the msvc toolchain.
So the problem is that stdc++ isn't a standardized header, and isn't included in msvc. How can I link directly to each of these c++ standard library headers instead of using stdc++?
I already tried the naive approach of just trying to link to math like so
println!("cargo:rustc-flags=-l dylib=math");
which did not yield any results

boost/date_time/gregorian/gregorian.hpp, where can I find the files in order to compile the code that uses the following #includes in c++,

These are the two includes which require certain files, libraries for
them to work. Also am using Code Blocks as my IDE.
#include <boost/date_time/gregorian/gregorian.hpp>
#include <boost/date_time.hpp>
‏

iOS: building a static library from c++ code fails

I have been trying to create an static library out of C++ code by following this tutorial. If I trying to build the project some error occurs.
#include <limits> "limits" file not found
for example.
I have been trying different build settings, e.g. C++ Standard Library with no luck.
Rename the implementation files from .cpp to .mm did not work also. Is there an workaround to solve this issues?
Try using #include <limits.h> instead of #include <limits>

variable named TYPE_BOOL(c++ code) is conflicted with ios macro

I'm trying to build protobuf c++ into ios.
But its implementation contains a TYPE_BOOL enum variable that conflicts with TYPE_BOOL in ios macro. And compile failed.
How to solve this?
There are a few reasonable (but hacky) options:
#include any protobuf headers that use TYPE_BOOL before you #include any iOS headers. Example:
#include <google/protobuf/descriptor.h>
#include <ConditionalMacros.h>
This lets you use iOS's TYPE_BOOL in your own code, but not protobuf's TYPE_BOOL.
#include the iOS header, then #undef TYPE_BOOL before you #include the protobuf header. Example:
#include <ConditionalMacros.h>
#undef TYPE_BOOL
#include <google/protobuf/descriptor.h>
This lets you use protobuf's TYPE_BOOL in your own code, but not iOS's TYPE_BOOL.
If you need both definitions, this might work (not tested):
#include <google/protobuf/descriptor.h>
// Make a copy of TYPE_BOOL before it is hidden by a macro.
const google::protobuf::FieldDescriptor::Type PROTOBUF_TYPE_BOOL =
google::protobuf::FieldDescriptor::TYPE_BOOL;
#include <ConditionalMacros.h>
Now use PROTOBUF_TYPE_BOOL when you need the Protobuf definitions.
Note that google/protobuf/descriptor.pb.h also defines a TYPE_BOOL. It can be solved in the same way, but most people don't use that header, so I left it out of the examples.

What's the benefit of including common files in one single header file?

I was looking at the doom3 code on github and I notice something unusual. Several files have only one include for a file called idlib/precompiled.h and this file have includes for several other headers like
...
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <assert.h>
#include <time.h>
#include <ctype.h>
#include <typeinfo>
#include <errno.h>
#include <math.h>
...
and to program headers
#include "../framework/BuildVersion.h"
#include "../framework/BuildDefines.h"
#include "../framework/Licensee.h"
#include "../framework/CmdSystem.h"
#include "../framework/CVarSystem.h"
I wonder if there's any good reason for that, because that's the first time I see such thing
This is called precompiled headers. The main benefit is dramatically increased compilation speed.
All the headers in precompiled.h are compiled only once per project. Without precompiled headers, each header content would be compiled multiple times: for each .cpp file it is included in.
Dependencies are best served with an include-once in the using source (pragma, guarding defines). That involves a very small overhead as you get a tree of repeated includes: including a header while including a header.
However for the standard libraries are/were sometimes not so well organized and to provide a standard base of headers this was easiest. It also reflects a kind of "module" idea, bundled headers for the basic layer.
As to local includes: it is likely to be non-object-oriented lazyiness, not expressing dependencies.