|
If you say that, cause I heven't needed to do it yet.
|
|
|
|
|
Lucky you
|
|
|
|
|
Yep you can acheive that with c#
Two heads are better than one.
|
|
|
|
|
I don't understand. What can I achieve with C#?
|
|
|
|
|
Everything you can with other managed languages, thay all come from the same cooking pot.
Two heads are better than one.
|
|
|
|
|
That's not true. You cannot use unmanaged C++ code "just like that" from C#. You can use Interop and Marshalling, but with C++/CLI you can use unmanaged C++ classes and functions directly.
You can argue of course that you don't need to use unmanaged code directly, so you don't need this feature of C++/CLI, but this is one thing you can not do with C# (or VB.Net, F#,...).
|
|
|
|
|
Andromeda Shun wrote: but this is one thing you can not do with C#
IIRC there are a few other things you can do in C++/CLI that you can't in C#, e.g., deterministic finalization, STL on managed types.
Kevin
|
|
|
|
|
Yes DLLImport is nice but their are times, big times, when it is a headache. For example working with DirectShow c++ code, i.e. capture filters written in c++, and wrap up all the nasty code with working with the video capture graph so that in your little c# program you can work with a high-level webcam capture entity as if it was written in c# itself.
Yes you could write a c++ dll that returns some data and exposes some control functions... but that means in c# you have to have a ton of interop wrapper definitions, and every time you change something in the c++, well now you gotta update the c#.
C++/CLI is the easier way to NOT have to do any of that. You can work with the c++ objects from the comforts of a CLI class... i.e. you can work with the pointers and safe pointers etc etc. You can specify how to cleanup and finalize objects in the c++/cli... so that means no calling of "Free()" functions in c#, or else memory leaks... just let the object go out of scope like a c# object.
And when you compile, simply add reference to the C++/CLI project and off you go. No pesky interop stuff to work with... CLI really a pleasure to work with (intellisense would help) :P
|
|
|
|
|
salrouge wrote: I don't see the utility of C++/CLI
See here.[^]
Kevin
|
|
|
|
|
I happen to like the :: syntax, instead of just dots, to differentiate the difference between a namespace and, for example, a member of that name space!
System::Drawing::Graphics->DrawSomething();
System.Drawing.Graphics.DrawSomething();
The price payed for (apparent) simplicity is a loss of understanding as to exactly what it is you're working with. M$'s original plan was to supplant VB with C# - so consider.
Also, when you find you have to mix managed & unmanaged code, C++/CLI has it's own lively acronym: IJW (IT JUST WORKS).
/xml> "The difference between genius and stupidity is that genius has its limits." - Albert Einstein
| "As far as we know, our computer has never had an undetected error." - Weisert
| "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010
|
|
|
|
|
|
I use it to write standard windows dlls and still have the power of the .net framework.
More info - I write add-ins to a software package that can only pull in standard windows dlls. But, I am a straight C programmer. I am also a C# programmer. I never got into C++. But with C++/CLI I've got the best of both worlds. I can code standard windows dlls and I can create great GUI in C# and I can tie the two together and pass data back and forth using C++/CLI.
Lee
L. Lee Saunders
|
|
|
|
|
I am still having to use VC6, a twelve year old development package, that is what comes from working on a large legacy package that can not be easily updated. I am begining to feel that there could be future in COBOL :>)
|
|
|
|
|
In 2004 I was using VC+= 1.52 on a legacy project. However, I was able to create a workspace in VC++ 6, add the files and get intellisense, better editor etc. Then I'd switch to VC++ 1.52 to build.
Kevin
|
|
|
|
|
Ouch. I've done such a port, and I can certainly understand a reluctance on the part of any organisation to commit to it. However, knowing what I do of the advantages of moving on from VC6 (compliant for loop scoping is only the start of it) I can honestly say the pain of porting to a more compliant (and secure) version of Visual C++ is likely to be worth it in most cases. As a bonus, once you get past the initial VC6 -> VS2xxx pain, upgrading to newer versions is far, far easier.
If it helps, we recently had a request to support VC5 in one of our tools!
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
So, there's still a way to get it work (at least partially).
|
|
|
|
|
CLI - I prefer to stay from programming languages which have acronyms I cannot really expand.
My signature "sucks" today
|
|
|
|
|
I am using C++/CLI and one thing I figured out:
a) Other Interop technologies such as COM Interop and PInvoke are better and easier to manage. Actually, you will end up using it anyway depending on the project.
b) In case other technologies cannot be avoided use C++/CLI as a small thunk layer. Do not write majority of .NET code in C++/CLI. In fact, purely managed classes in C++/CLI are not worth the trouble anyways as IDE support for C# is far better than that of C++/CLI.
|
|
|
|
|
Right!
I have found it easier to create mixed .NET assemblies (w/ C exported functions). Something that's not possible in other languages.
Cheers
|
|
|
|
|
Ernest Laurentin wrote: create mixed .NET assemblies w/ C exported functions
What are those? Where and why you would use them?
|
|
|
|
|
It's a DLL with both managed and unmanaged code. It still has DllMain .
So far I've used them to create Media plugin, custom directshow filters.
These things are very difficult to work with in .NET.
|
|
|
|
|
I agree PInvoke works fine, I could convert entire MFC project of various types into a dll that is called from C#, nevertheless I thought C++/CLI is more convenient.
Now, with new "feature" of VS 2010, I use 3 instances of Visual Studio: one 2008 with the same C++CLI project, another 2010 with dummy C# project and my C++CLI project on VS 2010. This allows me use intellisense from C++ on 2008 and for new APis from C# on 2010 when I need to write code in C++ on 2010.
It is a big fun and very convenient - thanks to Microsoft!
|
|
|
|
|
Member 617025 wrote: It is a big fun and very convenient
Not bad
|
|
|
|
|
Rama Krishna Vavilala wrote: a) Other Interop technologies such as COM Interop and PInvoke are better and easier to manage.
Ok, I gotta ask, since every time I use it it chews up way too much time and leaves me feeling dirty all over: what's your trick to using P/Invoke without descending into the depths of paranoid madness wondering if you got some subtle alignment or calling convention wrong and won't realize it 'till your app hits the field?
I will agree that COM Interop is pretty painless though, provided you're ok limiting yourself to simple interfaces and automation datatypes.
|
|
|
|
|
Shog9 wrote: what's your trick to using P/Invoke
Keep it to minimal use and simple functions.
I use 85% COM Interop, 10% C++/CLI (just because I was mostly doing C++) and 5% PInvoke.
|
|
|
|
|
Micro$oft still doesn't get it.
There are two ways you can move the programming world:
1 - by giving, such as adding C#
2 - by taking, such as making something else more difficult or taking it away
Method 1 can be used with success, C# being a deliberate example.
As for Method 2?
You'd think that even they would have figured out, after the colossal failure of Vista, that people can and do 'just say no'. If the regular rabble are willing to turn around and ignore their upgrade, surely they could have guessed that developer will, too.
My wisdom not being at the same lofty level as theirs, I can only assume that they think there's some reason for a C++ programmer to overspend on VS2010 if they don't want to even use the CLI.
So, now, once again, they have to undo their damage.
Luckily, for many of us, we've also adapted to another Micro$oft favorite: don't install anything until the first few service packs have been released.
Behold, Micro$oft. I Stand Facing East In Order That I May Fart in Your General Direction.
/xml> "The difference between genius and stupidity is that genius has its limits." - Albert Einstein
| "As far as we know, our computer has never had an undetected error." - Weisert
| "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010
|
|
|
|
|