|
*** 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.
|
|
|
|
|
Unbe Kant wrote: I'd rather let the native code itself allocate all the memory it needs
by all means, if the managed world is not involved in the buffer nor its content, let the native world take care of it. However as soon as the managed side is involved, put it in charge of allocation. It is easier and more efficient that way.
Unbe Kant wrote: I wouldn't want garbage collection anyway.
Why is that, do you have good reasons to avoid it? allocating and later collecting one array will be cheaper than copying its contents once.
Unbe Kant wrote: allocating memory by the managed code using "new"?
by any means suitable to your purpose. Could be new Something() or Image.FromFile() or anything that allocates (and initialized) a buffer or a chunk of memory.
Unbe Kant wrote: I would still have managed memory ... with produces overhead I must avoid.
I do image processing with C# and native C or assembly, I let C# do the overall stuff, the input/output, the GUI and the buffer allocations, and C/assembly the bitlevel stuff.
There are some app categories for which .NET isn't suited but for most of those Windows isn't suited either. Those are discussed seldomly on this site though.
Care to tell more about your app? What is it about, how big are your matrices, how many are there, and how long would a native function take typically?
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.
|
|
|
|
|
Hi Luc
Thank you again for your input. I will do as you say, since I believe that your experience is much bigger than mine. Actually, I am more familiar with Linux coding in C/C++.
Here is some more info about our app:
- It is a scientific programm solving integral equations numerically
- One single matrix: 128^3 double precision float (64bit) (Not that big, I know. It's not one single calculation, but the number of iterations that consumes time. Furthermore, future goal is to increase the precision AND dimensionality i.e. 128*x^(3*y) ... as soon as RAM becomes as cheap as a grain of sand  )
- Need some 10 matrices simultaniously in RAM
- The current command-line based implementation is pure C++, however, even here the matrices are stored in arrays rather than STL stuff, because matrix-operations are carried out by C style Intel Math Kernel Libraries
- Intel C/C++ Compiler
- Time consumption per iteration on a single CPU 3GHz Intel CPU: 0.5s
- Still: We need a couple of thousand iterations until the calculation converges, which makes a single calculation lasting approx. half an hour for only this task
- Some post-interpolation stuff
Future plans:
- Extending matrix dimensionality to six while, of course, lowering the resolution (e.g. 32^6 or even more if we get the RAM )
- GUI (Here's where .NET becomes interesting)
- Database connection (dito)
Now maybe things become clearer. So what do I want to do?
- Let C# load the parameters (e.g. matrix size)
- Let native C++ allocate the memory for the 3D/6D arrays and pass the pointer to C# (using a pinned pointer, right?). However, these MUST be pure arrays since Intel Math Kernel Libraries accept nothing else
- Let C# fill the matrix
- Let C++ perform all calculations. I hope to be able to somehow handle the messaging between C++ and C# during the calculation for e.g. updating a progess bar
- When finished, let C# present and save the resulting matrix
As you can see, the managed world is hardly involved in the buffer. I could, of course, also let the managed code allocate the memory for the initial matrix and then copy it. But should I?
You asked:
> Why is that, do you have good reasons to avoid it?
> allocating and later collecting one array will be
> cheaper than copying its contents once.
Is this true in my case? Wouldn't the performance decline dramatically if GC was involved in the matrix calculations? It's just that I've heard (yet, never tested, maybe I should give it a try) that the performance of such calculations with matrices stored in managed memory is always lower.
> There are some app categories for which .NET isn't suited but
> for most of those Windows isn't suited either.
O dear - would that be one of those categories? 
Regs
|
|
|
|
|
Unbe Kant wrote: would that be one of those categories?
absolutely not. as I understand it, you have a lot of data (filling almost all the memory)
and a heavy computation, nothing extremely dynamic or real-time oriented.
The one thing you must avoid is having your data copied, since 1) that slows things down, and 2) that requires extra memory (worst case: twice as much).
I still believe allocating on the managed side is the right way to go. I can't imagine Intel insists on allocating the data arrays themselves. They must accept pre-existing arrays, so allocate them in the managed world, use GCHandle to pin them down and get their pointer, then pass that to the native code, where Intel should accept them as if they were allocated with native code outside the Intel library. (If the Intel library would need some working space, which remains entirely hidden from the outside, so be it).
There is one caveat: managed memory blocks larger than some 80-85KB get allocated on the "large-object heap" which never gets compacted (moving the data would be too expensive). If lots of such blocks, all with different sizes, would be allocated and deallocated in random order, memory could become fragmented preventing a future allocation although sufficient free memory is available.
The relevance of a fragmentation risk depends on the variability of your array sizes, and the frequency of allocating and freeing such arrays. The subject is carefully avoided in all but the deepest documentation and discussions.
If, for some reason, you have to allocate all memory on the native side, you will have to:
- either provide managed but pointer-based code to fill the array yourself;
- or rely on one of the Marshal.Copy() overloads to fill part of the arrays (doing it by parts to prevent you needing twice the memory), maybe row-by-row.
BTW: I trust both Intel's library and yourself are sufficiently performance-aware to avoid multi-dimensional arrays; in my experience a little effort to linearize them immediately pays off.
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.
|
|
|
|
|
>as I understand it, you have a lot of data (filling almost all the memory)
>and a heavy computation, nothing extremely dynamic or real-time oriented.
Precisely.
> I still believe allocating on the managed side is the right way to go.
Ok, convinced, I believe you and will make it so.
> I can't imagine Intel insists on allocating the data arrays themselves
Of course, it doesn't. Please forgive me if I didn't made this point clear enough: The application must allocate the memory and pass the pointer all along with the number of elements (eg. m and n for a m*n matrix)
> BTW: I trust both Intel's library and yourself are sufficiently performance-aware
> to avoid multi-dimensional arrays; in my experience a little effort to linearize them immediately
> pays off.
Sure, I wrote about multi-dimensional matrices, not arrays
Again thank you very much for taking the time helping me with your input. I shall now start experimenting
Regs
UK
|
|
|
|
|
Luc Pattyn wrote: IMO the rumors of C++/CLI being much better at interop than C# are highly overrated.
Luc, I hope you won't mind if I defer to these fellows facts as opposed to your opinion?
While there is no question that the Microsoft® .NET Framework improves developer productivity, many people have some concern regarding the performance of managed code. The new version of Visual C++® will allow you to set aside these fears. For Visual Studio® 2005, the C++ syntax itself has been greatly improved to make it faster to write. In addition, a flexible language framework is provided for interacting with the common language runtime (CLR) to write high-performance programs.
Many programmers think that C++ gets good performance because it generates native code, but even if your code is completely managed you'll still get superior performance. With its flexible programming model, C++ doesn't tie you to procedural programming, object-oriented programming, generative programming, or meta-programming.
Another common misconception is that the same kind of superior performance on the .NET Framework can be attained regardless of the language you use—that the generated Microsoft intermediate language (MSIL) from various compilers is inherently equal. Even in Visual Studio .NET 2003 this was not true, but in Visual Studio 2005, the C++ compiler team went to great lengths to make sure that all of the expertise gained from years of optimizing native code was applied to managed code optimization. C++ gives you the flexibility to do fine tuning such as high-performance marshaling that is not possible with other languages. Moreover, the Visual C++ compiler generates the best optimized MSIL of any of the .NET languages. The result is that the best optimized code in .NET comes from the Visual C++ compiler.
http://msdn.microsoft.com/en-us/magazine/cc163855.aspx[^][^]
Wait Luc, there's more
Summary: Explore the design and rationale for the new C++/CLI language introduced with Visual C++ 2005. Use this knowledge to write powerful .NET applications with the most powerful programming language for .NET programming.
C++: The Most Powerful Language for .NET Framework Programming[^]
MORE!!!
Some people think that Microsoft forgets C++ playing with C#, but C++ is still widely used language. Could you comment it?
Microsoft has absolutely *not* forgotten C++. Most shrink-wrap applications are C++ because it's the smallest, tightest way to build apps and requires the least support from the OS itself. There is tons of existing C++ code in the world and Microsoft has implemented pure magic in the managed extensions for C++. MC++ allows you to flip a compiler switch, recompile your C++ code and begin producing and consuming .NET types immediately, all without changing your unmanaged types. In addition, the MC++ IJW (It Just Works) technology provides the lowest overhead interop layer between managed and unmanaged code, making it the best way to bridge the gap between the two technologies. Also, VS.NET 2003 provides a C++ compiler that compiles unmanaged C++ code down to smaller and faster code than ever before, while increasing ANSI C++ compliance to the highest level of any C++ compiler that I know of. I can't say enough good things about Microsoft's continued support for C++. I don't know of anyone doing more.
Interview with Chris Sells[^]
|
|
|
|
|
Hi Mike,
there is a lot you wrote/copied/linked to that I agree with. Even when some of it may sound a little biased (MS has to promote .NET, has to make clear what the position is with repect to C++, it is only normal compilers and code generators get improved, etc).
However it is besides the point I was making or trying to make: once it has been decided a mixture of managed code and native code is needed (maybe because of existing native code), making the two worlds cooperate often can be achieved with C# and P/Invoke as efficiently and with the same performance as can be done with C++/CLI. I am not saying C# is better or worse than C++/CLI, I am only referring to its ability to interface well with the native world.
I have been doing a lot of interop over the years, dealing with huge amounts of numeric data going back and forth, and the one thing that really matters performance-wise is the data does not get copied. Well, that can be organized by allocating managed buffers (e.g. int arrays), then passing pointers (I tend to use GCHandle for that, even when sometimes a simple fixed would suffice).
Example: I created an image processing library using run-time generated assembly code (including MMX/SSE for Intel x86 and Altivec for PowerPC) and called from both .NET (C#, using P/Invoke) and Java (using some kind of JNI); the code was not PC specific, it had to run on non-Windows embedded systems too. In the end the SIMD code was almost as fast as a copy operation, so adding one or two copy operations to it would be unacceptable.
Some people claim the best way to call native code from C# is by providing a C++/CLI wrapper, and maybe this is correct for complex data structure situations (not sure), but I object to those anyway. KISS is one of my motto's, and with a KISS interface, C# + P/Invoke works great.
Hence my statement: "IMO the rumors of C++/CLI being much better at interop than C# are highly overrated."
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.
|
|
|
|
|
+5 for the links
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
