Converting Over To C#

[Guest bigspank]

I'm a newbie attempting to use C# instead of C++ and in need of assistance. I've notice that #includes are no longer used in C# (.NET 2003) and trying to figure out what's the best way to convert over the header file. Instead of stumbling through it or using C++, I would inquire here to see if anyone has done this allready.

Thanks

-Spank

[Nutster]

AutoIt is written using C++, not C#, so we will not likely be much help.

Reminder to me: Learn Java and then C#

[Valik]

Disclaimer: I do not know C# or any .NET language and I have minimal experience with .NET so what I say may be inaccurate or wrong. With that out of the way...

I think you might need to write a wrapper in .NET (Language of your choice, just as long as it's .NET) which wraps the C++ calls in the DLL. You would then be able to use that wrapper on top of the standard AutoIt DLL. As for implementing that, I have no clue.

Alternatively, you could use Managed C++. You should be able to use the header and the static or dynamic libraries in a .NET environment that way. Plus, it allows you to use .NET without having to learn both a new language and a new framework.

There are probably other solutions I'm not aware of. As I said, I'm not a .NET programmer. I messed with a little Managed C++ once but not really enough to learn much.

David, why learn Java at all? From everything I've heard on the web and what people who know both languages say, C# is a lot easier and better to use. Besides, everybody says C# is very similar to C++ and the transition should be a bit easier since you already know C++.

The whole .NET thing sounds neat and stuff. But in practice, I'm still on the fence about it. Mono is in development to port the CLR specification (Or whatever its called) to Linux; I don't know how good or bad it is. Also, I know Microsoft has added some non-CLR conforming stuff into the System namespace when it doesn't belong there, so that makes me a little worried that it'll take 20 years before Microsoft actually makes a standard compliant version available without all there messing about and confusing the piss out of people. And who knows how long until Linux has a standard compliant version ready enough that it's realistically possible to write cross-platform applications (It could already be to that stage, I don't know or care at this point).

[Nutster]

The big piece of bad news I hear about .NET is that all source is stored in the program, even when you "compile" the program. Hmm, I've heard of that somewhere else. So this means C# and VB.NET are just scripting languages.

The source code gets sent through a Just-In-Time compiler at run-time. This means that your source can be read by somebody else, even if I do not want them to. This appears to apply to both C# and VB.NET.

I like the old VB's that do not need store source, but store pure executable code, compiled for the local machine. Sure it cuts down on portability, but it improves performance as well as security, something that Micro$oft has yet to really embrace, other than that big guy at the front door of the offices.

Edited May 11, 2004 by Nutster

[Guest bigspank]

Thanks for the replies.

I'm going to look into a wrapper solution which will be a lot of work, but will at least give me a better understanding on how C# namespaces and resource dependencies work. If I come across anything useful, I'll be sure to share.