Questions about stackalloc and inline structure arrays.

  • Thread starter Thread starter Daniel O'Connell
  • Start date Start date
D

Daniel O'Connell

Two questions here:

1. Is there any particular reason why when using stackalloc, the code byte
*buffer = stackalloc byte[50]; works, but code like byte *buffer; buffer =
stackalloc byte[50]; is considered incorrect syntax? Was this an oversight,
a stylistic design, or is there a technical reason it won't work?

2. I was reading an older(circa 2000) question[1] posted to one of these
groups in which Eric Gunnerson mentions that the C# team was still talking
about a way to declare inlined arrays of base types in structures,
basically:
struct myStruct
{
int[5] fiveArrays; //5 ints all in a row in memory, obviously would need
better syntax
}
out of my own curiosity, has anything about this come up recently? Is the
team still considering it? Is something perhaps coming up(or is there
something there in 1.1 I've not managed to find?).

1. http://tinyurl.com/vi0s
 
Daniel,
2. I was reading an older(circa 2000) question[1] posted to one of these
groups in which Eric Gunnerson mentions that the C# team was still talking
about a way to declare inlined arrays of base types in structures,
basically:
struct myStruct
{
int[5] fiveArrays; //5 ints all in a row in memory, obviously would need
better syntax
}
out of my own curiosity, has anything about this come up recently? Is the
team still considering it? Is something perhaps coming up(or is there
something there in 1.1 I've not managed to find?).


It's planned for v2.0 (Whidbey), with the syntax

struct myStruct
{
fixed int fiveArrays[5];
}



Mattias
 
Mattias Sjögren said:
Daniel,
2. I was reading an older(circa 2000) question[1] posted to one of these
groups in which Eric Gunnerson mentions that the C# team was still talking
about a way to declare inlined arrays of base types in structures,
basically:
struct myStruct
{
int[5] fiveArrays; //5 ints all in a row in memory, obviously would need
better syntax
}
out of my own curiosity, has anything about this come up recently? Is the
team still considering it? Is something perhaps coming up(or is there
something there in 1.1 I've not managed to find?).


It's planned for v2.0 (Whidbey), with the syntax

struct myStruct
{
fixed int fiveArrays[5];
}

Good to hear, I havn't had the time to read everything on the new C# specs.
Interestingly, this is one feature I never use but always miss.

Thanks
 
Daniel,
Good to hear, I havn't had the time to read everything on the new C# specs.

IIRC the preliminary spec they published only covered the four new big
features (generics, partial types, iterators and anonymous delegates).
There are more little things being added as well. You can see them at
the end of Anders Hejlsberg's PDC slides (session TLS320) at

http://msdn.microsoft.com/events/pdc/agendaandsessions/sessions/default.aspx

Interestingly, this is one feature I never use but always miss.

It will probably mostly be used in interop situations. It's limited to
the primitive value types, and I believe it only works in an unsafe
context. There's no runtime support for it, so they implement it by
generating a nested opaque value type of size
sizeof(elementType)*numElements, include a field of that type in place
of the fixed array, and then index into that with pointer offsets.



Mattias
 
Mattias Sjögren said:
Daniel,
specs.

IIRC the preliminary spec they published only covered the four new big
features (generics, partial types, iterators and anonymous delegates).
There are more little things being added as well. You can see them at
the end of Anders Hejlsberg's PDC slides (session TLS320) at

http://msdn.microsoft.com/events/pdc/agendaandsessions/sessions/default.aspx
Hrmm, I find it interesting that there has been less coverage on some of
these minor features added to the language. the namespace alias qualifier
looks interesting, as does the addition of static classes. Every forum,
newsgroup, mailing list, etc I read has been up in arms over generics and
iterators, but they say very little about some of these other features that,
while not massive, are still interesting.
It will probably mostly be used in interop situations. It's limited to
the primitive value types, and I believe it only works in an unsafe
context. There's no runtime support for it, so they implement it by
generating a nested opaque value type of size
sizeof(elementType)*numElements, include a field of that type in place
of the fixed array, and then index into that with pointer offsets.
Thats basically what I was considering using it for, unsafe code. The
thought came up most recently when I was faced with the possible need to
write an ISO-9660 image reader class, and the thought came to me to use
unsafe code to map to the headers for reasons explainable only by having
spent enough time in C that pointers just wont' stop dancing around in my
head. That basically illustrates my point, I've thought about the need for
inline arrays in structures a number of times, and in the vast majority of
them I realize that they wouldn't be a good way to go even if it was
possible currently, thus a feature I would very rarely use but would always
miss, because I know that eventually I am going to need it for something.
 
Daniel,

It's been a while since we did stackalloc, but IIRC, we only allowed it as
an initialization because we wanted to limit the impact that it would have
on the language.

To answer your other question about when we'll be talking about other
features, we're working on a merged version of the language spec (new
features + old features), and we're also working on a "what's new in C#"
spec.

Both should show up on the C# dev center on MSDN. The second one should (and
I don't own it....) be up there in the next week or so.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Eric Gunnerson said:
Daniel,

It's been a while since we did stackalloc, but IIRC, we only allowed it as
an initialization because we wanted to limit the impact that it would have
on the language.

Interesting. stackalloc was about the only keyword I had any trouble with.
When I first came across it and started playing with it, I managed to miss
the requirement that it only be used in an initalization. So, I'm sitting
there wondering why exactly visual studio and the spec mentions this
keyword, but the compiler won't accept it. It took a bit to figure out.
To answer your other question about when we'll be talking about other
features, we're working on a merged version of the language spec (new
features + old features), and we're also working on a "what's new in C#"
spec.

Both should show up on the C# dev center on MSDN. The second one should (and
I don't own it....) be up there in the next week or so.

I'll keep my eyes open, thanks for the info.
--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
Daniel O'Connell said:
Two questions here:

1. Is there any particular reason why when using stackalloc, the code byte
*buffer = stackalloc byte[50]; works, but code like byte *buffer; buffer =
stackalloc byte[50]; is considered incorrect syntax? Was this an oversight,
a stylistic design, or is there a technical reason it won't work?

2. I was reading an older(circa 2000) question[1] posted to one of these
groups in which Eric Gunnerson mentions that the C# team was still talking
about a way to declare inlined arrays of base types in structures,
basically:
struct myStruct
{
int[5] fiveArrays; //5 ints all in a row in memory, obviously would need
better syntax
}
out of my own curiosity, has anything about this come up recently? Is the
team still considering it? Is something perhaps coming up(or is there
something there in 1.1 I've not managed to find?).

1. http://tinyurl.com/vi0s
 
Back
Top