|
The horror!! The horror!!
Boris Jabes (MSFT) has just revealed in a VC++ blog post (in the comments no less; I wonder when we'd have found this out if Sunil Joshi had not asked about it) that Visual Studio 2010 Intellisense, you know, that incredibly fast and reliable rearchitecture of Intellisense that we've all been waiting for, will not support C++/CLI!
http://blogs.msdn.com/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
This is stunning to me. Boris's statement is effectively that "we don't think you spend all that much of your time in C++/CLI anyway!" Puh!
If you are at all invested in C++/CLI, please head over to that blog post and add a comment indicating your displeasure with this disturbing turn of events.
Thanks,
Eric
|
|
|
|
|
Wow, I thought it was just an issue in the beta. No wonder intellisense is faster! it's doing half the work. This really blows (to put it lightly).
Don't be overcome by evil, but overcome evil with good
|
|
|
|
|
Yeah, that really blows.
A main reason I dropped C++/CLI for new development a while back.
Still use it as little as possible - for interop, but that's it.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
modified on Thursday, May 28, 2009 1:55 PM
|
|
|
|
|
Intellisense is for sissys 
Real programmers use vi. ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
BTW today is Friday for me, have a great weekend ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
|
BTW, did you see the followup just below about VC10 intellisense. You are getting hooked up baby!!!
|
|
|
|
|
Heh yeah....but like you said, Intellisense is for sissys.
Intellisense won't make it a first=class .net language. I want to see C++/CLI usable
everywhere C# is, with all the same VS tools!
I spend so much more time with C# now, that when I go back to do some C++/CLI,
it feels like I can't do anything....weird 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
*** UPDATE ***
Boris Jabes has now posted a clarification in the comments of the referenced blog post stating that the lack of C++/CLI Intellisense support in Visual Studio 2010 is temporary and will be remedied as soon as possible after Visual Studio 2010 ships. This is certainly an improvement compared to the original statement, which did not say anything about the lack of C++/CLI support being temporary.
http://blogs.msdn.com/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
|
|
|
|
|
That's a great news. I remember Herb Sutter saying future versions of VS will have good support for C++/CLI. But Boris really surprised me.
|
|
|
|
|
As with all other combinations of C++, C# and different versions of Visual Studio, I suspect I'll be trusting Visual Assist X[^] to provide me with decent Intellisense 
They don't yet have VS2010 support, but judging by their track record (I've been using the product for 8/9 years....), they'll have support pretty soon after VS2010 is released.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hello
I am trying to convert from "String ^" to std::String on VC++ 2005. I use this piece of code:
std::string s;
String ^ ss = "hello";
s = ss;
I have got the following error:
error C2679: binary '=' : no operator found which takes a right-hand operand of type 'System::String ^' (or there is no acceptable conversion)
Any idea?
Thanks
|
|
|
|
|
You need to work with Marshal::StringToHGlobalAnsi
String^ ss = "hello";
const char* characters = reinterpret_cast<const char*>(Marshal::StringToHGlobalAnsi(ss).ToPointer());
std::string s(characters);
|
|
|
|
|
What about FreeHGlobal()? Memory leak?
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Forgot about that  Thanks
|
|
|
|
|
String ^ss = "hello";
IntPtr ps = Marshal::StringToHGlobalAnsi(ss);
std::string s((char*)ps.ToPointer());
Marshal::FreeHGlobal(ps);
With VS 2008, there's also
#include <msclr\marshal_cppstd.h>
...
String ^ss = "hello";
std::string s(msclr::interop::marshal_as<std::string>(ss));
Mark Salsbery
Microsoft MVP - Visual C++
modified on Thursday, May 28, 2009 5:28 PM
|
|
|
|
|
|
de nada... no problemo
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I'm trying to hook the ReadFile API like FileMon does.
Do you have an example of ReadFile?
Please help me .....
|
|
|
|
|
Hi all
I have some question dealing with garbage collection and overall performance of native objects created within managec C++/CLI.
1. Consider std::BusinessClass being a native code. I could create an instance within a managed object with "new" (and not "gcnew", I don't want the gc-overhead:
std::BusinessClass* pBs = new std::BusinessClass();
Question: Is the memory allocated here really not managed by the gc? Is anything managed here? Any performance loss compared to this object created within a native code?
2. Is creating the native object within managed code recommended anyway (native DLL -> managed caller)? Or is it recommended to make use of a native wrapper (native DLL -> native Wrapper -> managed caller)?
3. How was memory managed if I had created the object in 1. with "gcnew" and if memory was allocated from within the native object by "new"? What if it wasn't freed after destruction of the object? Memory leak?
4. Is it possible to create a native C++ object in C# similar to the example in 1.? Or do I need to warp a native function around the native class, so that the function can be called by C#?
Thanks for your anwers in advance.
Sincerly
U. Kant
|
|
|
|
|
1 - If BusinessClass is not a ref class, memory allocated won't be managed by GC.
2 - It depends on your requirements. If possible, try to use managed classes over native classes.
3 - If your BusinessClass is not managed (ref class BusinessClass), you can't use gcnew on that. gcnew creates objects on managed heap and memory will be managed by garbage collector. If it is native class and instantiated using new, memory will be on unmanaged heap and you are responsible for cleaning it. If you are not cleaning, you will have a memory leak.
4 - C# uses P-Invoke to communicate with native classes. I don't think that C# supports writing native classes like the example 1.
|
|
|
|
|
Hi all
I guess this is an old issue for you, however, I am lacking this information and would appreciate any hint, answer or link to FAQ etc... Please, if you could really be bothered considering my scenario:
- New project planned "from scratch"
- Performance critical tasks: native C++ class library
- All the rest: managed code
My first question is: In such a "from scratch" project, where is the benefit in using managed C++ instead of C#, if performance critical tasks are outsourced to native C++ anyway?
Thanks for you answer, suggestions etc in advance.
Best Regs
U. Kant
|
|
|
|
|
Unbe Kant wrote: Performance critical tasks: native C++ class library
Looks like you are doing premature optimization. AFAIK, Managed code can be faster than native C++ code sometimes as JIT compiler does optimizations(specific for the running machine) on the IL. C++ code is compiled, but not optimized for the machine where it will be running. Having said that, specific optimizations on C++ can improve the performance drastically and managed code can be nowhere near to that. So choose the decision carefully as communication between unmanaged-managed may be performance costly.
As I said, when using managed languages, try to use managed code whenever possible.
Unbe Kant wrote: In such a "from scratch" project, where is the benefit in using managed C++ instead of C#
I think there is no benefits if you are writing everything as managed code. If you are mixing managed and unmanaged code, C++/CLI can take advantage. C++ interop is more efficient than p-invoke. So that unmanaged-managed communication can be better. Other advantage I felt is, C++/CLI supports generics like C# and it also supports C++ templates for managed classes. Here[^] is an explanation for why C++/CLI supports both.
When you do mixed mode compilation in C++/CLI, the generated assemblies are tough to disassemble with tools like reflector. I have read in the C++/CLI team blog saying that it produces more optimized IL than any other CLI languages.
|
|
|
|
|
Dear Navaneeth
thank you for your answer. As to the new information I have thanks to you, I would carry on like this:
1. Write native C++ *classes* for all business stuff
2. Use C# for all the presentation layer and the I/O
3. Write native wrapper functions that create native objects and also implement algorithms that use them
4. C# reads data from db, fiel etc., passes data to the wrapper function - FIRST conversion
5. Native C++ classes calculate, allocate, shift and so on
6. When calculation is finished, the result is returned to C# in order to present, serialize etc. - SECOND conversion
So I have only two conversions throughout the whole workflow. All performance critical tasks are carried out by the native code.
To be more precise about "performance critical tasks": I plan to do some multidimensional matrix-matrix calculations, and furthermore, iteratively - which means that I have to carry out the matrix-matrix operation over and over again. Actually, I would like to make use of Intel's Math Kernel Library, which is native C binary. BTW, is this possible? Can I link C libraries generated with the Intel Compiler using Visual Studio? Both binaries are supposed to be compatible, are they?
So this is my plan. Does it sound reasonable to you? 
U.K.
|
|
|
|
|
Hi,
if you are in charge of all the code, both managed and unmanaged, you can choose the interface between both worlds and get excellent performance, no matter which managed language you use.
IMO the rumors of C++/CLI being much better at interop than C# are highly overrated.
When done properly, bulk data does not need to be copied at all; a key factor is making your managed side do the allocation of all buffers that need to be passed from one side to the other.
Simple situations can be implemented with the "fixed" keyword; more complex situation may require the buffer/array pointers to remain in native use after their first passing returns, you then need the GCHandle class.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Dear Luc
thank you very much for your answer.
> IMO the rumors of C++/CLI being much better at interop than C# are highly overrated.
That's good news for me, since I would like to avoid C++ wherever possible. Although C++ invoke is more convenient and allows for the creation of native objects, I don't think I really need it, because I plan to minimize the communication between managed/unmanaged to exactly two events: 1. Managed object passing parameters and data to native object (via P/invoke and native wrapper function) and 2. native object returning results (again via native wrapper).
> a key factor is making your managed side do the allocation of all buffers that need to be passed from one side to the other.
O really? I'm surprised! I'd rather let the native code itself allocate all the memory it needs, since I though allocation and management of natively allocated memory was faster?!? 
I wouldn't want garbage collection anyway. So do you really mean allocating memory by the managed code using "new"? Of what benefit would that be? Or do you mean creating vars, arrays etc. in the managed code and, then, passing pinning or even interior pointer to the native code? If so, I don't think I would do that, since I would still have managed memory in any cace, with produces overhead I must avoid.
Thanks & best regs
U.K.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
