Develop Reference

How generate a DLL from C program for use in a C# project

I need to use a program made in C for a C# project , and for this I need to generate a DLL in Visual Studio 2013, anyone have any tutorial or know how to do it?
I want make a DLL for a structs and read/write functions in C, cheers guys.

You have to use p/invokes. I think this is very often discussed here. Take a look at: Access a method from a DLL from C# program

DLL is probably overkill for what you are doing. You can just write a C procedure and P/Invoke it using CDecl. The problem is that you need to know a whole lot for this. If you are simply trying to iterate over an array fast for a performance critical section, you are better off using structs in C#, slapping unsafe on your method, and then using pointers and addresses to do what you want to do. Code that looks a whole lot like C/C++ is perfectly legal in C#.
See a reference here: MSDN : Unsafe Pointers
Also fished out a somewhat dated reference showing how to P/Invoke the visual c Runtime printf function as an example. Keep in mind that things get really hard when you need to give a pointer to a function and when you need to read offsets etc. to pass around structs. You'll need to pin anything you pass into the method to stop it from being moved by the garbage collector, which will also have performance implications.
MSDN: CDecl P/Invoke example

Why does a function need to be declared before it's defined or used?

In C its optional. In C++ one "MUST" declare a function before its used/defined. Why is it so? Whats the need? We don't do that in C# or Java.
Funny thing is while we are defining a function. The definition itself has a declaration even then, we need to declare. God knows why?

Funny that you mention that, just this week Eric Lippert wrote a blog post related to your question :
http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx
Basically, this is related to how the compiler works. The C# and Java compilers make several passes. If they encounter a call to a method that is not yet known, that's not an error, because the definition might be found later and the call will be resolved at the next pass. Note that my explanation is overly simplistic, I suggest you read Eric Lippert's post for a more complete answer...

Java and C# specify both the language and the binary object file format, and they are multi-pass compilers.
As a result, they are able to peek at later definitions or those that were compiled separately.
C doesn't work this way for several reasons:
Without using managed code it is a lot harder to define a machine-independent object format with type information
C deliberately allows bypassing the type mechanisms
When originally defined, there generally wasn't enough memory to run sophisticated compilers, nor were there prototypes to read anyway
C programs must be arbitrarily large with system-specific library and search path mechanisms. All of this gets in the way of defining an object-module-based type system
Part of the C portability and interoperation basis is the "input language only" nature of the specification
Until recently, even the limited one-pass nature of C was still barely practical for large programs. Something like Java or C# would have been out of the question: you could take a vacation and your make(1) would still not be done

Basically, it's down to how you write the compiler for the language.
In C++, the decision has been to make a one pass compilation possible. To do that, you (or rather the compiler) need to be able to first read the declaration of all classes, methods and the like and then read the implementation (or in C++ terms, the definition). In Java and C#, the compiler first reads through all the code generating what corresponds to what the C++ compiler generates when reading the header files. The C#/Java compiler then reads the implementation (aka definition). So, in C++, the developer is asked to write the declaration whereas in C#, the compiler runs through the code multiple times doing the declaration work for the developer.
As an aside, other languages used to ask you to write the functions in the order you needed them (if function B uses function A, you have to define A first). Most of those languages had constructs to allow you to get around this. In (Turbo) Pascal, the solution was, in a kind, the same as in C++.

C++ vs. Java/C# - Single-pass compiler (C++) vs. multi-pass compiler (Java & C#). Multiple passes allow Java and C# compilers to peek at future types and functions prototypes.
C++ vs. C - The C feature to have default declaration is basically a bug, fixed in C++. It causes problems, and it is an enabled warning for gcc. In C++ the arguments form part of the function exported name (name-mangling), so must be known before the correct function can be called.

In C++ one "MUST" declare a function before its used/defined. Why is it so? Whats the need? We don't do that in C# or Java.
I would like to say, that is not true. Yes, in C++ you have to define a function signature (prototype), before referring to it. But you may leave the implementation for a later time.
In Java that does not work: you cannot call the method of some class without having that class compiled (note: together with implementation) and available in javac classpath. So, Java is more strict in this sense.

translate C++/CLI into C#

How I can translate small C++/CLI project to c#

One roundabout, manual way would be to compile your C++/CLI project and open the output assembly in Reflector. Disassemble each class, have it convert the disassembled IL to C#, and save that code off.
As for an automatic way to do it, I can't think of any off the top of my head.
Those things being said, are you sure you really want to convert your project to C#? If your C++/CLI project uses any unmanaged code, you'll have a difficult time coming up with a purely managed equivalent. If the project is more or less composed of pure CLR code, and it was written in C++/CLI for the sake of being written in C++/CLI, I can understand wanting to convert it to C#. But if there was a reason for writing it in C++/CLI, you may want to keep it that way.

IMHO, line by line is the best way. I've ported several C++ style projects to a managed language and I've tried various approaches; translators, line by line, scripting, etc ... Over time I've found the most effective way is to do it line by line even though it seems like the slowest way at first.
Too much is lost in a translator. No translator is perfect and you end up spending a lot of time fixing up the translated code. Also, translated code as a rule is ugly and tends to be less readable than hand crafted code. So the result is a fixed up, not very pretty code base.
A couple of tips I have on line by line
Start by defining all of the leaf types
For every type that has a non-trivial (freeing memory) destructor, implement IDisposable
Turn on the FxCop rule that checks for lack of Dispose calls to catch all of the places use used stack based RAII and missed it
Pay very close attention to the uses of byref in C++.

I haven't tried it, but I just googled it and found this: http://code2code.net/
According t it, you shouldn't fully rely on the code it produces:
You accept that this page does only half the work.
Futher work on your part is required. In most cases, the translated code will not even compile.
Also, read this: Translate C++/CLI to C#

What makes the Java compiler so fast?

I was wondering about what makes the primary Java compiler (javac by sun) so fast at compilation?
..as well as the C# .NET compiler from Microsoft.
I am comparing them with C++ compilers (such as G++), so maybe my question should have been, what makes C++ compilers so slow :)

That question was nicely answered in this one: Why does C++ compilation take so long? (as jalf pointed out in the comments section)
Basically it's the missing modules concept of C++, and the aggressive optimization done by the compiler.

I think the most difficult part is not the need to compile the header files (unless they are really big, but you can use precompiled headers in that case). The worst part is always the fact that C++'s grammar is too wildly context-sensitive. Despite the fact I like C++, I feel sorry for anybody who has to write a C++ parser.

There are a couple of things that make the C++ compiler slower than those of Java/C#. The grammar is much more complex, generic programming support is much more powerfull in C++, but at the same time it is more expensive to compile. Inclusion of files work in a different way than importing modules.
Inclussion of header files
First, whenever you include a file in C++ the contents of the file (.h usually) are injected in the current compilation unit (include guards avoid reinjecting the same header twice), and this is transitive. That is, if you include header a.h, that in turns includes b.h, your compilation unit will include all code in a.h and all code in b.h.
Java (or C#, I will talk about Java, but they are similar in this) don't have include files, they depend on the binaries from the compilation of the used classes. This means that whenever you compile a.java that uses an object B defined in b.java, it just checks the binary b.class, it does not need to go deeper to check the dependencies of B, so it can cut the process earlier (with just one level of checking).
At the same time, including files only includes the language definitions, and processing it requires time. When the Java/C# compiler reads a binary it has the same information but already processed by the compilation step that generated it.
So at the end, in C/C++ more files are included and at the same time processing of those includes is more expensive than processing of binary modules.
Templates
Templates are special in their own way. They can be precompiled, but they are usually not (for a good set of reasons). This means that in all compilation units that use std::vector the whole set of vector methods used (unused template methods don't get compiled) is processed and the binary code generated by the compiler. At a later step, during linking, redundant definitions of the same method will get dropped, but during compilation they must be processed.
Support in Java for generics is more limited in many ways. At the end, for example, there is only one Vector class binary, and whenever the compiler sees Vector in java what it does is generating type checking code before delegating to the real Vector implementation (that stores plain Object) and that is not generic. The compiler does provide the type warranties, but does not compile Vector for each type.
In C# it is, once again, different. C# support for generics is more complex than that of Java, and at the end generic classes are different than plain classes but anyway they get compiled only once as the binary format has all required information.

Because they do something quite different, C++ compiler produces optimized native code whereas C#, VB .Net and Java compiler produce an intermidiate language than when you first execute the application is turned into native code, and that is why you get slow loading of application in Java etc. the first time you execute the application.
The C++ compiler has to do the full optimization where the JITed languages optimize when you execute the application.
Someone would argue that you have to measure C++ compile time = Java compile time + time for JITing the first time you load the application if you want to be correct, but i don't think that would be right and fair because you are comparing native languages to JITed, or else oranges to apples.

The C++ compiler must repeatedly compile all the header files and there are lots of them, so this is one thing that slows it down.

One of the more time consuming tasks when compiling is code optimization.
Javac does very little optimization on the code when doing the compilation. Optimization is instead done by the JVM when running the application.
A C/C++ needs to be optimized when compiling since optimization of compiled machine code is hard.

You got it right in your last sentence: it's not java or C# that's fast to compile, it's C++ that is exceptionally slow to compile, due to its complex grammar and features, most importantly templates

If you think javac is fast try Jikes.... (see http://jikes.sourceforge.net/)
It is a Java Compiler written in C++. Unfortunately they haven't kept up with the latest Java Compiler specs but if you want to see fast this is it.
Tony

I think part of it is the complexity of the languages. C++ is incredibly mutable, with the ability to override pretty much any operator or piece of syntax (like overriding the () operator). This means the compiler has to do a lot more work just to determine what operations to actually run, even for simple things. Java and C# don't have this issue, as the syntax is fixed, and they're generally much simpler to parse.

It's a bit difficult comparing bytecode languages like java with natively compiled languages like C++. A better comparison is Delphi vs C++, where Delphi is much faster to compile. Since this has nothing to do with optimization or byte code, it must be due to differences in language syntax and the relative performance of includes vs. modules/units.

Is Java compiler fast?
The Java to class translation shall be blindingly fast since it is just a glorified zip with some syntax checking so to be fair if compared to a real compiler that is doing optimization and object code generation the "translation" from Java to class is trivial.
Did a comparison with fairly small program "hello world" and-and compare to GCC (C/C++/Ada) and found that javac was 30 times slower, and it got even worse in runtime?

Turning C# methods into C++ methods

I'm exploring various options for mapping common C# code constructs to C++ CUDA code for running on a GPU. The structure of the system is as follows (arrows represent method calls):
C# program -> C# GPU lib -> C++ CUDA implementation lib
A method in the GPU library could look something like this:
public static void Map<T>(this ICollection<T> c, Func<T,T> f)
{
//Call 'f' on each element of 'c'
}
This is an extension method to ICollection<> types which runs a function on each element. However, what I would like it to do is to call the C++ library and make it run the methods on the GPU. This would require the function to be, somehow, translated into C++ code. Is this possible?
To elaborate, if the user of my library executes a method (in C#) with some arbitrary code in it, I would like to translate this code into the C++ equivelant such that I can run it on CUDA. I have the feeling that there are no easy way to do this but I would like to know if there are any way to do it or to achieve some of the same effect.
One thing I was wondering about is capturing the function to translate in an Expression and use this to map it to a C++ equivelant. Anyone has any experience with this?

There's CUDA.Net if you want some reference how C# can be run on GPU.

To be honest, I'm not sure I fully understand what you are getting at. However, you may be interested in this project which converts .Net applications / libraries into straight C++ w/o any .Net framework required. http://www.codeplex.com/crossnet

I would recommend the following process to accelerate some of your computation using CUDA from a C# program:
First, create an unmanaged C++ library that you P/Invoke for the functions you want to accelerate. This will restrict you more or less to the data types you can easily work with in CUDA.
Integrate your unmanaged library with your C# application. If you're doing things correctly, you should already notice some kind of speed up. If not, you should probably give up.
Replace the C++ functions inside your library (without changing its interface) to perform the computations on the GPU with CUDA kernels.

Interesting question. I'm not very expert at C#, but I think an ICollection is a container of objects. If each element of c was, say, a pixel, you'd have to do a lot of marshalling to convert that into a buffer of bytes or floats that CUDA could use. I suspect that would slow everything down enough to negate the advantage of doing anything on the gpu.

What you could do would be to write an own IQueryable LINQ provider, as is done for LINQ to SQL to translate LINQ queries to SQL.
However, one problem that I see with this approach is the fact that LINQ queries are usually evaluated lazily. In order to benefit from pipelining, this is probably not a viable solution.
It might also be worth investigating how to implement Google’s MapReduce API for C# and CUDA and then use an approach similar to PyCuda to ship the logic to the GPU. In that context, it might also be useful to take a look at the already existing MapReduce implementation in CUDA.

That's a very interesting question and I have no idea how to do this.
However, the Brahma library seems to do something very similar. You can define functions using LINQ which are then compiled to GLSL shaders to run efficiently on a GPU. Have a look at their code and in particular the Game of Life sample.