Shawn A. Van Ness wrote:
Ok, so I grant that GC.KeepAlive(this) does have some effect. But
what does this have to do with IntPtr fields?
The (somewhat dubious) assumption is that an IntPtr represents an
unmanaged resource.
I mean, is there something special about IntPtr (like, maybe the
PROTECTED] On Behalf Of
Bogdan Lachendro
Sent: Friday, November 19, 2004 16:27
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] const modifier in method
parameter - managed c++
On 2004-11-19 16:22, Jeroen Frijters wrote:
Actually there is a difference between the method
signatures
Mark Bugeja wrote:
Thanks for the input guys, but the actual type of the element
is not the source of our problem.
For the moment, ignore that I ever mentioned
XmlElementAttribute... What I need to know is if there is any
way to apply an attribute to the return parameter of a method
Shawn A. Van Ness wrote:
Two simple questions for which I should know the answer, but don't:
Does XP SP2 include the .NET framework? If so, what
version(s)? Does it include any bits from the upcoming
.NET service packs [1]?
I can't give any authoritive answers, but I have the following
Shawn A. Van Ness wrote:
My advice to component vendors of the world: build your dll assemblies
against the earliest version of the runtime you care to support.
Exactly! I have a 1.0 component written in MC++ and I do this too (even
though this is very painful, because the MC++ 1.0 compiler is
Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeroen Frijters
Sent: Monday, May 17, 2004 6:17 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Large structures
John Elliot wrote:
Is there any safeguard in place that could
Arlie Davis wrote:
I have a few questions for the advanced CLR people here. I
haven't been able to find any satisfactory answers elsewhere.
Consider value types / structures in CLR, and passing them as
arguments to methods. Does the MS CLR *always* copy the entire
structure onto the
Frans Bouma wrote:
Because the DX api is a COM api,
We're talking about the *Managed* DirectX API. So your entire message
doesn't make any sense.
Regards,
Jeroen
===
This list is hosted by DevelopMentor® http://www.develop.com
Some .NET courses you may be
Frans Bouma wrote:
Although there is one weird thing:
(and you know more on this than I do I think): the D3D structs are
redefined in these formats:
[StructLayout(LayoutKind.Sequential, Size=24, Pack=1),
CLSCompliant(false), MiscellaneousBits(65), DebugInfoInPDB]
public struct
Frans Bouma wrote:
Why is it irrelevant, if I may ask?
It's irrelevant to the question that we were discussing (which was why
did MS design the Managed DirectX API like this?).
Well, perhaps the answer lies somewhere in the reason why
D3DMATRIX is defined as:
Stefan Holdermans wrote:
JF I would argue that the behavior described by the original
JF poster is in fact a bug. The spec says (part. I 8.5.3.1
JF Visibility Of Type): The visibility of a type definer is the
JF same as that for the type from which it was generated. (as I
JF
Frans Bouma wrote:
Ok, I see your point.
It is indeed weird, I didn't notice that, my appologies.
If you look at Volume.LockBox() for example you see this:
public GraphicsStream LockBox(Box box, LockFlags flags)
{
return this.LockBoxInternal(ref box, flags, 0);
}
Indeed weird why
John Elliot wrote:
Is there any safeguard in place that could catch this type of
thing?
As long as you don't use unsafe code, there is no way to get in
trouble with a ref to a struct (they are always local to one thread).
Except, of course, by calling a native method that hangs on the pointer.
I disagree. While the implementation is close to what you describe, that
really isn't relevant. In the type system, there really are distinct
types for each array type.
I would argue that the behavior described by the original poster is in
fact a bug. The spec says (part. I 8.5.3.1 Visibility Of
Peter Partch wrote:
ElementCount is read-only
Ugh. Sorry about that. It isn't even what you asked about.
I tried to use SetCustomAttribute to emit a MarshalAsAttribute, but that
hangs (!)
I looked at the Rotor code and SetCustomAttribute actually has support
for pseudo-custom attributes, so in
I wrote:
I tried to use SetCustomAttribute to emit a
MarshalAsAttribute, but that hangs (!)
I looked at the Rotor code and SetCustomAttribute actually has support
for pseudo-custom attributes, so in theory it should work,
but it looks like there is a bug somewhere in the runtime.
I don't
to this, but when you
say Whidbey are you referring to a particular .NET runtime
version (what number? generally available? if so where?), a
particular version of Windows (what number? generally
available?) -- when .NET is supposed to be the same on them
all -- or both?
At 05:10 AM 2/5/2004, Jeroen
For the archives.
Regards,
Jeroen
-Original Message-
From: Markus Bergkvist [mailto:[EMAIL PROTECTED]
Sent: Monday, October 20, 2003 15:09
To: Jeroen Frijters
Subject: RE: J# and access modifiers
Hi,
I don't have any account on Advanced DotNet, so perhaps you could add
the
following
It is a feature. Java's package access is namespace based, so the J#
compiler people decided (by default) to map all non-private access
modifiers to public. You can use the /securescoping option to change
this behavior.
Regards,
Jeroen
-Original Message-
From: Moderated discussion of
I was able to reproduce it with the command line compiler.
C:\csc /O test.cs
Microsoft (R) Visual C# .NET Compiler version 7.10.3052.4
for Microsoft (R) .NET Framework version 1.1.4322
Copyright (C) Microsoft Corporation 2001-2002. All rights reserved.
C:\test
in if
in else
Regards,
Jeroen
Both approaches have ups and downs. It's probably best not to call
virtual methods from the constructor.
The reason C# (and Java too) do it this way is probably because of
efficiency. Changing the vtable pointer (what C++ does) isn't possible
in C#/Java because that would confuse the garbage
It's hardcoded in the compiler. If you've got the Rotor sources
installed, the check is done in TYPESYM::isSpecialByRefType().
http://dotnet.di.unipi.it/Content/sscli/docs/doxygen/csharp/symmgr_8cpp-
source.html#l02546
Regards,
Jeroen
-Original Message-
From: Frans Bouma
It gets worse. Look at the following code:
using System;
class Class1
{
static void Main(string[] args)
{
ArgIterator iter = new ArgIterator(Foo(__arglist(1, 2, 3)));
}
static RuntimeArgumentHandle Foo(__arglist)
{
return __arglist;
}
}
This is effectively the same as
ArgIterator is a special type. It contains a pointer to the stack, so it
isn't allowed to escape the current method. Otherwise, you'd have a
pointer pointing into the middle of nowhere.
Regards,
Jeroen
-Original Message-
From: Bogdan Lachendro [mailto:[EMAIL PROTECTED]
Sent:
16, 2003 11:45
To: [EMAIL PROTECTED]
On 6/16/2003 11:39 AM, Jeroen Frijters wrote:
ArgIterator is a special type. It contains a pointer to the
stack, so it
isn't allowed to escape the current method. Otherwise, you'd have a
pointer pointing into the middle of nowhere.
OK, I
Shawn A. Van Ness wrote:
Another question. Aren't these KEYS provided to you as enum?
I'm needing to p/invoke the actual Win32 functions -- not
using the Microsoft.Win32.RegistryKey stuff.
I seriously doubt the numerical values of the enum you
mention are the actual UINT_PTR values I
It's quite simple:
public static Type MakeRef(Type type)
{
return type.Assembly.GetType(type.FullName + );
}
Regards,
Jeroen
-Original Message-
From: Jason Whittington [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 07:13
To:
As long as the cast succeeds performance should be the same, if the cast
fails, isinst is much faster than castclass (because castclass has to throw
an exception, which is expensive).
Note that neither of these instructions look at the elements of the array,
i.e. only the type of the array is
Hi,
You are correct in assuming that the fact that the type hasn't been created
is causing the problem. The solution is to use:
ModuleBuilder.GetType(string).
Regards,
Jeroen
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED]] On Behalf
Whoops. I wasn't quite awake yet. In Java it isn't legal either. Well, the
example below would be legal, but that is because protected members also
have package (or default) access. If you move A and B to two different
packages, the below code doesn't compile in Java either.
Regards,
Jeroen
Please see
http://discuss.develop.com/archives/wa.exe?A2=ind0209CL=DOTNET-CLRP=R2
458I=-3 for an explanation of what actually changed. In short, the
change docs are wrong.
Regards,
Jeroen
-Original Message-
From: Moderated discussion of advanced .NET topics.
Logically they are very similar, but Mutex wraps the OS mutex while
Monitor is something that is native to the .NET framework. This has
several consequences:
- Mutex can be used to synchronize accross different processes, while a
Monitor is local to the AppDomain
- A Monitor is *much* faster than
The finalizers start running before you've finished the look, and they
decrement Class1.iterations which is used in the loop, thus you're
allocating less than 1000 objects.
Also, it is *very* bad practice to close the filestream in the
finalizer. You only ever should release *unmanaged*
Exactly! For specific configuration scenarios it might be possible to
get around this problem, but in general that isn't possible (at the
moment). I don't know if you're familiar with Palladium, but that would
help solve these types of problems.
Regards,
Jeroen
-Original Message-
1) I know of at least one scenario where Full Trust is demanded by the
CLR. When you call a strong-named shared library that doesn't have the
AllowPartiallyTrustedCallersAttribute, the CLR will only allow this if
the caller has full trust. I don't know if this is what you're seeing,
though.
2) I
35 matches
Mail list logo
