|
Hi there!
As for me, I don't code C++/CLI with Visual Studio, so I don't care (professionally). However, I care personally, since IntelliSense is a very useful and time-saving feature, and removing it for C++/CLI is very annoying.
Greetings,
Shun
|
|
|
|
|
They do plan to bring it back but it's not clear whether via service pack or new version. I get the impression it will be the latter.
In the meantime this[^] is the only solution.
Kevin
|
|
|
|
|
Yes, VisualAssist really is a great piece of software, making VisualStudio usable
|
|
|
|
|
Oh yes. In my opinion Visual Studio is a shadow of Visual Studio + Visual Assist it just makes the whole thing so much better.
Cheers
Tom
Philosophy: The art of never getting beyond the concept of life.
Religion: Morality taking credit for the work of luck.
|
|
|
|
|
I don't see the utility of C++/CLI ! if I want to code with C++ I use the native code by MFC, and if I want to use the managed code I choice C# which I find easyer and best.
|
|
|
|
|
And if you need to pass data between the managed and the unmanaged word? That's what I'm using C++/CLI for...
|
|
|
|
|
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?
|
|
|
|