On 11/28/2011 03:52 PM, so wrote:
On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha <max...@spambox.com> wrote:
No, it has nothing to do with the IDE. The article describes a visual
tool for viewing meta-data stored in a .NET binary. You don't have to
use it.
Specially for you, die-hard IDE haters, this is how to use the
terminal to create a mono app and library:
I started to use vim/cmake "after" years of using IDEs, and one of the
best if not the best VisualStudio.
1. Library:
nano lib.cs
----
using System;
public class Lib
{
public static void hello() { Console.WriteLine("We don't need no
header crap"); }
}
----
Compile that into a library, lib.dll:
dmcs lib.cs -target:library
2. Host:
nano app.cs
----
class App
{
public static void Main()
{
Lib.hello();
}
}
Compile and run the app:
dmcs app.cs -reference:lib.dll
./app.exe
We don't need no header crap
Now how do you know you have a "Lib", and it implements "hello", what
rule enforces that?
If this is all it does, you are overlooking the most important point of
header files.
Could you clarify what is the most important part? If you want to use a
library, you would need to read its docs anyway. The interface files
won't be of much help (D's ones will, since dmd liberally pours
implementations into them). If the docs are unavailable or outdated, you
can always extract the declarations from the library:
monop -a -r:lib.dll
lib
Version=0.0.0.0
Culture=neutral
PublicKeyToken=null
public class Lib {
public Lib ();
public static void hello ();
}
Creating separate interface files, taking trouble to push them around
along with the library and then feeding them to the compiler are
needlessly redundant steps. Or what am I missing?
Your information about "serious" programming is a bit outdated.
What i mean by "serious" is that, if you "need" a specific language for
some task what you are doing is serious.
Because you are falling back to a less known and probably more complex
tools/languages, it is much harder to replace you.
I am still waiting for the next-gen game engine, next-gen video
decoder/encoder, next-gen ... from those serious languages you mention.
I am not ridiculing anything, aren't these the facts?
The fact is that apps with tight real-time requirements cannot be
developed in C# for obvious reasons, and compilation models are
irrelevant to the fact.
Ok, I am not a C# advocate. I hate it no less than C++ or D. It just
happens that its compilation model is superior.
