stackalloc on .net CF

52 views
Skip to first unread message

Eric Pearson

unread,
Jan 20, 2003, 5:09:30 PM1/20/03
to
Does anyone know of any issues using stackalloc in C# on the compact
framework?

I get an invalid program exception any time I try to use it.

I know I can use fixed(), but if I have 5 fixed variables I'd like to avoid
the nesting.


Jeffrey Paul [MS]

unread,
Jan 22, 2003, 12:43:48 AM1/22/03
to

you can include more than one variable in a fixed() statement:

fixed (byte* pBuffer = bBuffer, pResponse = bResponse)
{
}


--
Jeffrey Paul
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.


"Eric Pearson" <pleas...@newsgroup.only> wrote in message
news:uzFQVBNwCHA.2492@TK2MSFTNGP10...

Frank Peschel-Gallée [MS]

unread,
Jan 22, 2003, 7:50:54 PM1/22/03
to

Eric,
we didn't expect any good use of stackalloc for C#/VB.NET programs.
Considering the complexity of the implementation (dynamic stack growth
inside a method, clean-up in the event of an exception).

May I ask you why you would like to use it? This would be helpful input for
our planning process.

Thanks
Frank

Eric Pearson

unread,
Jan 23, 2003, 6:44:27 AM1/23/03
to
I have a method that needs to fill in many LPTSTR (in C# as char*, and I've
made sure unicode is defined) that have to be allocated in managed code,
then my unmanaged fills it in.

This is what I want to avoid:
fixed(blah) {
fixed(blah) {
fixed(blah) {
fixed(blah) {
}}}}

so I thought
char* somvar = new char[some_length]

would be much much cleaner.

"Frank Peschel-Gallée [MS]" <fra...@online.microsoft.com> wrote in message
news:UERCxlnwCHA.2208@cpmsftngxa08...

Eric Pearson

unread,
Jan 23, 2003, 7:12:39 AM1/23/03
to

From that response, are you saying it's simply not supported?

If it's simply not supported, a compiler error would be helpful too.


"Frank Peschel-Gallée [MS]" <fra...@online.microsoft.com> wrote in message
news:UERCxlnwCHA.2208@cpmsftngxa08...

Eric Pearson

unread,
Jan 23, 2003, 7:13:39 AM1/23/03
to
Ah, when I wrote this I hadn't yet read Jeffrey's response.

Thanks JP!

"Eric Pearson" <er...@pdi-home.com@pdi-home.com> wrote in message
news:u6Ek7StwCHA.1296@TK2MSFTNGP11...

Frank Peschel-Gallée [MS]

unread,
Jan 23, 2003, 12:52:58 PM1/23/03
to

Eric,
if you compile against the .NETCF libraries you should get a compiler error
(at least when compiled with C#, I can't tell off the top of my head if
VB.NET has this keyword at all). This is the error message I get from the
C# compiler when one of the fields is marked as volatile:

error CS0518: The predefined type
'System.Runtime.CompilerServices.IsVolatile' is not defined or imported

Does this answer your question?

Also, please have a look at the thread 'Why does "volatile" give a compiler
error?'.

Eric Pearson

unread,
Jan 23, 2003, 2:14:18 PM1/23/03
to
nope,

1 static void Main()
2 {
3 DoSomething();
4 }
5 public unsafe void DoSomething()
6 {
7 char* c = stackalloc char[16];
8 }

compiles just fine in my csdproj (whether it's an SDE class library or app)
Doesn't even give a warning.

(I'm using Final Beta, .Net Framework v1.1.4322, MSDE 2003 v7.12292)

I put a breakpoint at line 3. The app deploys to the device, and i can
break at 3 just fine. I step into DoSomething and get
"An unhandled exception of type 'System.NotSupportedException' occurred
in NatApp.exe"

(same thing whether or not I break).

So I guess the answer is no, it's not supported, but it DOES still compile,
a very confusing and important issue I believe should be resolved before
release if it's not too late.

-Eric Pearson
epearsonAT_GLobeRanger_com

"Frank Peschel-Gallée [MS]" <fra...@online.microsoft.com> wrote in message

news:lB5g4gwwCHA.1308@cpmsftngxa06...

Frank Peschel-Gallée [MS]

unread,
Jan 23, 2003, 3:43:09 PM1/23/03
to

wow, I gave you a reasonable answer to a question you didn't ask.

You are right, the C# compiler does NOT complain about a stackalloc
declaration and I'm afraid we wont have this error message in the shipping
version either. As if that would make it any better, I agree that this is
not a desirable outcome. Unfortunately there is a similar mismatch with
asynchronous delegates; you can compile the source code just fine, but you
wont be able to execute it.

Independent of the compiler/runtime mismatch I'm still curious to learn why
you wanted to use stackalloc? Was it just because of the perceived
limitation of the lock statement (and as the consequence, more convoluted
source code)?

Eric Pearson

unread,
Jan 24, 2003, 8:20:58 AM1/24/03
to

Yes, the reason for using stackalloc was to have much cleaner code than is
given with fixed.
But, the embedded syntax for "fixed" does lend to quicker, more deliberate
use of such pointers.

May I ask what the issue with async delegates is? I'd like to have my team
on the lookout.

-Eric Pearson
epearsonAtGloberangerCom

"Frank Peschel-Gallée [MS]" <fra...@online.microsoft.com> wrote in message

news:eDRE$$xwCHA.1872@cpmsftngxa06...

Eric Pearson

unread,
Jan 24, 2003, 8:55:23 AM1/24/03
to
WOW, the async delegate issue just threw our department way off. After
testing, an unbelievable amount of code will now have to be overwritten.

What is the recommended alternative?


"Frank Peschel-Gallée [MS]" <fra...@online.microsoft.com> wrote in message

news:eDRE$$xwCHA.1872@cpmsftngxa06...

Frank Peschel-Gallée [MS]

unread,
Jan 24, 2003, 6:15:25 PM1/24/03
to
Eric,
the short answer is to use System.Threading.ThreadPool instead (in order to
decouple the execution of the delegate from your "main" thread). I will
have to get back to you later with a more detailed response.

Scott Holden [MSFT]

unread,
Jan 29, 2003, 1:48:07 PM1/29/03
to
With regards to async delegates, they are not directly support in the .NET
Compact Framework. However, the asynchronous programming model works for
networking and has been implemented such that it appears that async
delegates work.
This is not true for System.IO, where the async programming model is not
supported.

For async programming (other than networking), you need to use
System.Threading.ThreadPool to simulate async delegates. For this, you just
pass in a sync delegate to ThreadPool::QueueUserWorkItem. You can pass in
an object that contains a wait handle and a result and any other context
required.

Scott.


Scott Holden
NET Compact Framework
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

Please do not send email directly to this alias. This alias is for newsgroup
purposes only. To correspond with me directly, remove the 'online' and
'news'
from my alias. This is to prevent automated spam to my alias.


Reply all
Reply to author
Forward
0 new messages