|
Jeff J wrote:
Shame on you for stimulating my attrophied neurons!
...and on you for coming out with something reasonable. I am still searching my references 
Anyway, let us know the results of your research. MC++ is here to stay!!!
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Hello Paul,
Paul Selormey wrote:
MC++ is here to stay!!!
Yes it is! In fact, I'm counting on VS.Net 2003 making it a lot more popular. Looks like we'll be some of the few ahead of the game.
Cheers,
Jeff
|
|
|
|
|
I played with the code you posted and some other stuff, but could not find a way to optimise the MC++ MSIL any further, but that may not be as much of a problem as we first thought. BTW, I can now see your MSIL was taken from optimised compiles.
Regarding your earlier question of whether the C# struct was being allocated on the stack or on the heap, I think I judged too quickly based on the MSIL. CIL documentation does not say much about newobj being applied to value types, however it "can" be used to allocate on the stack. It also says that it is rarely done this way. The blanks leave questions, but my guess is that newobj is itself optimised to return value types/structs as efficiently as possible, and in this unusual case, not on the heap. CLI instructions are not like low-level assembler op-codes, but more like convenient groups of instructions (actually, so are some op-codes).
Frustrated with MSIL, I moved to assembler, and found the following:
static MCppStruct GetStack() | public static CshStruct GetNew()
{ return MCppStruct(1,2,3); } | { return new CshStruct(1, 2, 3); }
-------------------------------------------------------------------------------------
00 push ebp | 00 push ebp
01 mov ebp,esp | 01 mov ebp,esp
03 sub esp,10h | 03 sub esp,10h
06 push edi | 06 push edi
07 push esi | 07 push esi
08 push ebx | 08 push ebx
09 <FONT color="green">mov ebx,ecx</FONT> |
0b <FONT color=blue>lea edi,[ebp-10h]</FONT> |
0e xor eax,eax | 09 xor eax,eax
10 <FONT color=blue>stos dword ptr [edi]</FONT> | 0b <FONT color=blue>mov dword ptr [ebp-10h],eax</FONT>
11 <FONT color=blue>stos dword ptr [edi]</FONT> | 0e <FONT color=blue>mov dword ptr [ebp-0Ch],eax</FONT>
12 <FONT color=blue>stos dword ptr [edi]</FONT> | 11 <FONT color=blue>mov dword ptr [ebp-8],eax</FONT>
| 14 <FONT color="green">mov ebx,ecx</FONT>
13 push 2 | 16 push 2
15 push 3 | 18 push 3
17 lea ecx,[ebp-10h] | 1a lea ecx,[ebp-10h]
1a mov edx,1 | 1d mov edx,1
1f call dword ptr ds:[00825230h] | 22 call dword ptr ds:[008151F0h]
25 mov edi,ebx | 28 mov edi,ebx
27 lea esi,[ebp-10h] | 2a lea esi,[ebp-10h]
2a movs dword ptr [edi],dword ptr [esi] | 2d movs dword ptr [edi],dword ptr [esi]
2b movs dword ptr [edi],dword ptr [esi] | 2e movs dword ptr [edi],dword ptr [esi]
2c movs dword ptr [edi],dword ptr [esi] | 2f movs dword ptr [edi],dword ptr [esi]
2d pop ebx | 30 pop ebx
2e pop esi | 31 pop esi
2f pop edi | 32 pop edi
30 mov esp,ebp | 33 mov esp,ebp
32 pop ebp | 35 pop ebp
33 ret | 36 ret
-------------------------------------------------------------------------------------
Most instructions are the same, except for those in blue. For the C# code, the JIT individually moves zero (in EAX) into the ints, whereas the MC++ stuff translates to using store-string (which requires loading the first address into EDI before the calls). They accomplish the same thing, and I don't recall that stos is slower than mov, so I'm stumped here. Best I can tell, performance should be about the same. The constructors were exactly the same. I don't see heap alloc here. So much for reading MSIL.
Is it possible that there is a difference in the code you used to test the performance? Maybe forgot to switch the MC++ to release mode as I originally did? Who knows, maybe the JIT settings used when debuggin' C# code, hides further optimisations done outside the IDE. I am assuming the disassembly view is accurate. Anyway, this has been a lesson for me that different byte codes can produce similar asm. Sorry for the short post 
Regards,
Jeff
|
|
|
|
|
Hello Jeff,
Thanks for the great work you are doing. The assembler results is interesting.
I now wish Andre could post his test projects so that we could examine them too.
Anyway, keep it up. I now have to take my IL lessons serious
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Whoops, it seems I did not get an e-mail notification. Something's going on in here, I see.
I'm short on time right now, so I cannot post the test code (maybe it was a test way too naiv at all). I'll post it when I have a little more time.
Thanks already for the interesting research, Jeff!
- Andre
|
|
|
|
|
Do not know if you read this, this was a late response from MS:
In response to your questions:
1)
The C# version is creating the struct on the stack. Turns out newobj
instruction can be used to create value types on the stack. I verified
this from the CIL spec (http:
for CLI Partition III , which documents the CIL instruction set), and by
writing a small MC++ sample that successfully consumes a value type
returned from C# in this manner.
2)
Our team has entered a suggestion to see if we can generate more efficient
CIL for the sample you provided.
--
Andrew Brown, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
I hope this is my last MC++ newbie question for a while...
( btw, thanks to previous answers I've got my cross platform, C++ & MC++ agnostic
threading code running. Thanks!  )
Is there any way to use templates for subclassing with managed classes ?
As in;
<br />
template<typename T><br />
struct foo<br />
{<br />
...<br />
};<br />
...<br />
__gc class bar<br />
: public foo<bar><br />
{<br />
...<br />
};<br />
..which doesn't compile. Adding a __gc to the foo-template doesn't help either. So, is there any way to do this, at all ?
cheers
-=jarl=-
|
|
|
|
|
-=jarl=- wrote:
I hope this is my last MC++ newbie question for a while...
I hope so too 
The Word version of the MC++ reference is available for download and it contains the dos and donts.
To your question, MC++ cannot derive from standard C++ and vice versa. A pointer of either can, however, be contained.
MC++ has no support for template (a lie actually !!!)
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Thank you very much!
-=jarl=-
Laird Of Glenmore
|
|
|
|
|
Is this;
<br />
void bar( data_struct_t * structure )<br />
{<br />
stuff_handle_ = GCHandle::Alloc( structure ); <br />
data_struct_t * tmp = static_cast<data_struct_t*>(stuff_handle_.Target);<br />
tmp->data_ = 1;<br />
} <br />
effectively as safe as, or the same as, this ?
<br />
void bar( data_struct_t * structure )<br />
{<br />
data_struct_t __pin * pinned = structure;<br />
pinned->data_ = 1;<br />
}<br />
-=jarl=-
|
|
|
|
|
Not really. GCHandle is more versatile than a pointer pinned via __pin. A pinned pointer only remains pinned while it is in scope, and if not set to zero. For example, when a function that uses pinned pointers returns, any pinned objects are no longer pinned. I suppose one could just say the __pin is used on stack-allocated pointers.
GCHandle, on the other hand, allocates on the heap (which is why Free() must be called to release an Alloc()-allocated GCHandle). There are a few options for GCHandles, but a regular one stays allocated between function calls, like any object allocated via malloc() or unmanaged new.
Which is safer? Well, that depends on the lifetime requirements you have for the object in question. If the handle needs to remain pinned/valid when it goes out of scope, GCHandle would be the safe bet.
Cheers
|
|
|
|
|
|
I think this overlaps somewhat with the general problems people seem to have with mixing C++ and MC++ code when pointers enters the equation, but anyways, here it the problem:
I have an unmanaged struct like so:
<br />
__nogc struct foo<br />
{<br />
int data_;<br />
};<br />
and then I have a managed struct like so:
<br />
__gc struct bar<br />
{<br />
foo is_this_unmanaged_still;<br />
};<br />
And...this doesn't compile.
: error C3633: cannot define 'is_this_unmanaged_still' as a member of managed 'bar'
I don't have my MC++ books yet, so excuse me if this is a bit of a naff question, but I am in the middle of porting some C++ code to be cross-C++/MC++ compatible and these little diddlers are causing me some immediate headaches...;P
cheers
-=jarl=-
|
|
|
|
|
..sorry, the question wasn't really in there now, was it...?
my question is: why doesn't this work ?
...I have feeling I might have asked a completely stupid question here.... 
-=jarl=-
|
|
|
|
|
Hello there,
The following compiles...
#include "stdafx.h"
#using <mscorlib.dll>
#include <tchar.h>
using namespace System;
__nogc struct StdHello
{
int nSomething;
};
__value struct MCHello
{
StdHello member;
};
int _tmain(void)
{
Console::WriteLine(S"Hello World");
MCHello hello;
hello.member.nSomething = 2003227;
Console::WriteLine(__box(hello.member.nSomething));
return 0;
}
I hope you see the difference It pays to buy a book, if not read the MC++ reference it is quite informative.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
Ok, yes, I am waiting impatiently for my books, so in the meantime I'm
abusing the nice people at CodeProj... 
Ok, you've answered my question; You can only contain a managed structure
in another managed structure.
cheers
-=jarl=-
|
|
|
|
|
-=jarl=- wrote:
Ok, you've answered my question; You can only contain a managed structure
in another managed structure.
No you did not get it, __nogc means StdHello is unmanaged. __value means MCHello is a managed structure, better called value.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
...ah....I see...;P
-=jarl=-
|
|
|
|
|
Hi!
Short form:
Imagine two managed functions<code>
void Class::Function1(SomeValueType val1)
void Class::Function2(SomeValueType * val2)</code>
And an unmanaged function:
<code>void Foo(void * pThis, void * pSomeValueType);</code>
pThis shall receive the this-pointer of Class , pSomeValueClass shall
receive a pointer to the SomeValueType instance. This, of course works:
<code>
void Class::Function1(SomeValueType val1)
{
Class __pin * pinnedThis = this;
SomeValueType __pin * pinnedVal = &val1;
Foo(reinterpret_cast<void*>(pinnedThis),
reinterpret_cast<void*>(pinnedVal));
}
void Class::Function2(SomeValueType * val2)
{
Class __pin * pinnedThis = this;
SomeValueType __pin * pinnedVal = val2;
Foo(reinterpret_cast<void*>(pinnedThis),
reinterpret_cast<void*>(pinnedVal));
}</code>
However, this works as well:
<code>
void Class::Function1(SomeValueType val1)
{
Foo(reinterpret_cast<void*>(&(*this)), reinterpret_cast<void*>(&val1));
}
</code>
How can it be, that &(*this) and &val1 are implicitely are converted to
__nogc pointers that can be castet to void*?
Thanks for your help!
Long form (including history and research):
Please take a view moments to read my post.
I am quite new to MC++ and .net, and so the following questions might sound
rediculous:
I am working on a managed classlibrary that wraps a small part of Direct3D8.
I know, Managed DX is out, however that is not what I need.
The classlib calls native functions. E.g. one function (it is one from
Direct3DX) has the following signature:
D3DXMATRIX * D3DXMatrixMultiply(D3DXMATRIX * out, D3DXMATRIX * mat1,
D3DXMATRIX * mat2);
First question: what is the better method: using DllImportAttribute to
import the method, or include the appropriate header file (<D3DX8.h>) and
lib ("D3DX8.lib")? Speed is more important than size.
So, now I have a __value class Matrix, which has the same memory layout as
D3DXMATRIX.
<code>
public __value class Matrix
{
public:
float M11, M12, M13, M14;
float M21, M22, M23, M24;
float M31, M32, M33, M34;
float M41, M42, M43, M44;
public:
void Multiply(Matrix * src);
};
</code>
Matrix::Multiply shall use D3DXMatrixMultiply. So naivly I tried this:
<code>
void Matrix::Multiply(Matrix * src)
{
D3DXMatrixMultiply(this, this, src);
}
</code>
OK, stupid me, the compiler complains that it cannot convert Matrix __gc
*const to D3DXMATRIX. Seems logical.
As a good citizen I use __pin pointers:
Second try:
<code>
void Matrix::Multiply(Matrix * src)
{
Matrix __pin * pThis = this;
Matrix __pin * pSrc = src
D3DXMatrixMultiply(reinterpret_cast<D3DXMATRIX*>(pThis),
reinterpret_cast<D3DXMATRIX*>(pThis),
reinterpret_cast<D3DXMATRIX*>(pSrc));
}</code>
Et voilá, it works. Being a bit proud of me, I ran Microsoft.DirectX.dll
(from Managed DX) through ildasm.exe and found out, that *their* version of
Matrix::Multiply only uses *one* pinning pointer. Furthermore their function
has a different sig: they provide the src Parameter by value.
<code>
void Matrix::Multiply(Matrix src);
</code>
Digging a bit more into the IL, I found out that say something like that:
<code>
void Matrix::Multiply(Matrix src)
{
Matrix __pin * pThis = this;
D3DXMatrixMultiply(reinterpret_cast<D3DXMATRIX*>(pThis),
reinterpret_cast<D3DXMATRIX*>(pThis),
reinterpret_cast<D3DXMATRIX*>(&src)); // use ptr of src
}</code>
Which - to my amazement - compiles. NO pinning pointer neccessary for src?
Because it is given by value?? Strange...
Now I tried something funny:
<code>
void Matrix::Multiply(Matrix src)
{
// we will deref this just to directly get the pointer of it
D3DXMatrixMultiply(reinterpret_cast<D3DXMATRIX*>(&(*this)),
reinterpret_cast<D3DXMATRIX*>(&(*this)),
reinterpret_cast<D3DXMATRIX*>(&src));
}</code>
Looks weird, but compiles!!
Second question: it seems obvious to me that calling this function has a
large overhead because Matrix src is passed by value. Looking at the IL of
the callee shows a cpobj, so I think this is not an appropriate solution.
(However, I wonder why MS did this that way...). Is it so?
Adding one and one, I tried the following:
<code>
void Matrix::Multiply(Matrix * src) // back to byref!
{
D3DXMatrixMultiply(reinterpret_cast<D3DXMATRIX*>(&(*this)),
reinterpret_cast<D3DXMATRIX*>(&(*this)),
reinterpret_cast<D3DXMATRIX*>(&(*src)));
}</code>
This indeed does not compile. Again the compiler argues about not being
abled to convert from __gc* to __nogc*.
Thanks for your patience!
- Andre
|
|
|
|
|
VizOne wrote:
How can it be, that &(*this) and &val1 are implicitely are converted to
__nogc pointers that can be castet to void*?
Essentially, __gc pointer and a __nogc pointer are the same thing, just values that hold memory addresses, whether pinned or not. So that you got away without pinning first, is just luck that the GC memory where the pointed-to objects were stored, was not moved during a garbage collection cycle. Pinning mostly just tells the GC not to move any object pointed-to by a pinned pointer.
If the GC moved the objects before the unpinned version of Function1() was called, there would be serious problems. However, there also is no guarantee that the GC would actually move those particular objects during collection; it is simply a possibility.
Incidentally, there are a few implicit things that occur in MC++ that are not well documented. Also, I recall reading somewhere that because of such things, any use of reinterpret_cast is discouraged in MC++. Of course, what would we do without it? MS is likely just covering their "tracks" with such warnings
Sorry, but I had trouble following your longer explanation, partly because the angle-bracketted portions of the casts were stripped (I sometimes forget to turn off HTML interpretation when I post too - very annoying, isn't it?), I am not too familiar with DirectX, and I could not see the IL for myself. However, I very much appreciate the extended explanation; it's short explanations that I more often have trouble interpreting.
Cheers
|
|
|
|
|
Thank you for your answer.
It is obvious that passing a cast (non-pin) pointer to a native function is dangerous for heap objects, as the GC may compact the heap, move objects etc. But what about __value object? They are stored on stack, aren't they? Will stack object be move during collection, too?
How heavy would you say is pinning a pointer? Is it a real performance issue if I keep the pointer pinned only for some native calculations that won't last more then a view microseconds?
- Andre
|
|
|
|
|
Me again!
Funnily, during a test I found out, that pinning the pointer first and then passing it to the native function works slightly faster...
Of course reinterpret_cast is an evil monster, but I have to use it here, haven't I?
Let's say, I have those structs:
<code>
[StructLayout(LayoutKind::Sequential, Pack=4)]
public __value struct ManagedStruct
{
float AddComponents();
float a, b, c;
};
#pragma pack(push, 4)
struct NativeStruct
{
float a, b, c;
}
#pragma pack(pop)
</code>
I guess these structs are guaranteed to be binarilly identical.
Now I have a function:
<code>
// the native version
#pragma unmanaged
float AddComponents(NativeStruct * p) { return p->a + p->b + p->c; }
#pragma
</code>
If I want to call this from within managed code via IJW, I'd do this:
<code>
float ManagedStruct::AddComponents()
{
ManagedStruct __pin * pinThis = this;
return ::AddComponents(reinterpret_cast<NativeStruct *>(pThis));
</code>
The reinterpret_cast is safe and ok, or not?
Is there another way of calling the native function?
- Andre
|
|
|
|
|
Hi VizOne,
Sorry for the late reply.
VizOne wrote:
But what about __value object? They are stored on stack, aren't they? Will stack object be move during collection, too?
Although __value objects are typically stored on the stack, they can also be put on the heap. Stack objects are the same in .Net as they are in regular C/C++, so they won't move.
How heavy would you say is pinning a pointer? Is it a real performance issue if I keep the pointer pinned only for some native calculations that won't last more then a view microseconds?
I did some preliminary tests too, and I could barely measure any performance differences. I forced GC collections during them. The GC does not collect very often under normal circumstances, so I don't see pinning as costly either. Your tests jibe with mine.
Of course reinterpret_cast is an evil monster, but I have to use it here, haven't I?
I always do, and MC++ code that ships with .Net uses it too. I really think MS is just playing it "safe". As I recall, reinterpret_cast was just discouraged. The software world would grind to a halt if such casts were never used
The reinterpret_cast is safe and ok, or not?
I usually call native functions from MC++ much like you do. As long as managed objects are pinned and the cast is appropriate, safety should not be of concern.
Cheers
|
|
|
|
|
Hi there!
I am currently currently working .net classes that implement IDisposable
following the msdn-guidelines, but I have a problem I hope you can help me
with:
Let's say these are my classes:
<br />
public __gc class B : public IDisposable<br />
{<br />
public:<br />
~B() { Dispose(false); }<br />
virtual void Dispose() { Dispose(true); GC::SuppressFinalize(this); }<br />
virtual void Dispose(bool arg) { }<br />
};<br />
<br />
<br />
public __gc class D : public B<br />
{<br />
public:<br />
virtual void Dispose(bool arg) { B::Dispose(arg); }<br />
};<br />
Looks nice, but does not work 
I can't do something like that:
<br />
D* d = new D();<br />
d->Dispose();<br />
as the hide-by-name convention does not allow that. In native C++ I could
use a using declaration:
<br />
public __gc class D : public B<br />
{<br />
using B::Dispose;<br />
<br />
};<br />
and everything was fine. However, this is not allowed in .net. Nevertheless
this implementation of IDispose is used throughout the framework. How did MS
do this? Did I miss something? Is it only possible in C#?
Thanks in advance.
- Andre (VizOne) Loker
|
|
|
|
|
Try this template:
public __gc class Hello : public System::IDisposable
{
public:
Hello(void)
{
}
virtual ~Hello(void)
{
Dispose(false);
}
void Dispose()
{
Dispose(true);
}
protected:
void Dispose(bool disposing)
{
if (disposing)
{
System::GC::SuppressFinalize(this);
}
}
};
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
