error C3699: '%' : cannot use this indirection on type 'System::String'

[Holger Grund]

What's special about System::String?

For instance, why can't one write a function like

using System::String;
void foo( const String% );

or what's wrong with:

int main() {
String s = "Snoopy"; // or just String s; if the ctor is not synthesized
};

Also ADL does not seem to work reliably with String.

I can understand why delegates and arrays are special from a FE
perspective (even though, I strongly believe it's another design flaw), but
what the heck is special about System::String?

-hg

[Nishant Sivakumar]

System::String does not support stack semantics, so you cannot have a String
or a String%, you can have a String^ or a String^% though.

--
Regards,
Nish [VC++ MVP]
"Holger Grund" <[e-mail]> wrote in message
news:Of**************@TK2MSFTNGP12.phx.gbl...

What's special about System::String?

For instance, why can't one write a function like

using System::String;
void foo( const String% );

or what's wrong with:

int main() {
String s = "Snoopy"; // or just String s; if the ctor is not
synthesized
};

Also ADL does not seem to work reliably with String.

I can understand why delegates and arrays are special from a FE
perspective (even though, I strongly believe it's another design flaw),
but
what the heck is special about System::String?

-hg

[Holger Grund]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote

System::String does not support stack semantics, so you cannot have a
String or a String%, you can have a String^ or a String^% though.

Yes, I see it is not. The question is why. I absolutely fail to understand
why one would design the language that way. For instance, why
can I write

ref class R{};
void foo( R% );
// or
void foo( System::Exception% );
int main()
{
R r;
System::Exception e;
}

-hg

[Nishant Sivakumar]

Sorry Holger,

I should have read your poster better.

When I first encountered this, I was puzzled too. String is probably one of
the most frequently used BCL class and to exclude it from stack semantics
seemed weird to me.

Here's a quote from Kapil Khosla [MSFT]

<quote>To answer your question. System::String is immutable. It means that
you
cannot modify the object once created. All methods exposed by the String
class actually create a new object containing the modification.

Thus, it doesnt make a lot of sense to have String object on the stack as we
cannot create a destructor for the String class. For all types where we
support the stack semantics, we require that the type must have a destructor
or the compiler should be able to create one.

Hope it helps,
Kapil </quote>

It doesn't really make a lot of sense to me. The fact that String is
immutable or that it does not have a destructor should not really have
affected the design decision to exclude it from stack semantics - unless I
am missing something. Perhaps, someone in the VC++ team would throw some
light on this.

--
Regards,
Nish [VC++ MVP]
"Holger Grund" <[e-mail]> wrote in message
news:O5*************@TK2MSFTNGP15.phx.gbl...

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote

System::String does not support stack semantics, so you cannot have a
String or a String%, you can have a String^ or a String^% though.

Yes, I see it is not. The question is why. I absolutely fail to understand
why one would design the language that way. For instance, why
can I write

ref class R{};
void foo( R% );
// or
void foo( System::Exception% );
int main()
{
R r;
System::Exception e;
}

-hg

[Holger Grund]

"Nishant Sivakumar" <ni**@nospam.asianetindia.com> wrote

When I first encountered this, I was puzzled too. String is probably one
of the most frequently used BCL class and to exclude it from stack
semantics seemed weird to me.

Here's a quote from Kapil Khosla [MSFT]

<quote>To answer your question. System::String is immutable. It means that
you
cannot modify the object once created. All methods exposed by the String
class actually create a new object containing the modification.
Oc, there are readonly instance methods and properties that do not
modify the string.
Thus, it doesnt make a lot of sense to have String object on the stack as
we
cannot create a destructor for the String class. For all types where we What's wrong with not creating a dtor or one that does nothing?
It doesn't really make a lot of sense to me. The fact that String is
immutable or that it does not have a destructor should not really have
affected the design decision to exclude it from stack semantics - unless I
am missing something. Perhaps, someone in the VC++ team would throw some
light on this.

Same here.

-hg

[Arnaud Debaene]

Holger Grund wrote:

I can understand why delegates and arrays are special from a FE
perspective (even though, I strongly believe it's another design
flaw), but what the heck is special about System::String?

Well, while you're at it, I'll appreciate if you could share your
understanding on the reasons for the limitations on arrays and delegates too
;-)

Arnaud
MVP - VC

[Holger Grund]

"Arnaud Debaene" <ad******@club-internet.fr> wrote

I can understand why delegates and arrays are special from a FE
perspective (even though, I strongly believe it's another design
flaw), but what the heck is special about System::String?

Well, while you're at it, I'll appreciate if you could share your
understanding on the reasons for the limitations on arrays and delegates
too ;-)

I didn't say I like it ;-) But obviously, there's some compiler magic
involved
with arrays and delegates. For instance, the CLR doesn't expose arrays
as specialiazations of ::cli::array<> as in C++/CLI. But there isn't
something
obviously different for String. IIRC it has a special short form at encoding
level and there are probably some subtleties involving string literal
conversions.

If you ask why a user should care about it, I don't know. In fact, I think
I filed a bug for the delegate case, which was closed as by design.

Yes, there it is:

http://lab.msdn.microsoft.com/Produc...d-f1595d7d7e45

-hg

[Peter Oliphant]

Read your bug report. Is the essence of your concern that you can't pass
what I think is called a 'stack semantic' form of a delegate? That is, this
is ok:

delegate void void_func_ptr(void) ;

void myMethod( void_func_ptr^ f ) {}

but this is not:

void myMethod( void_func_ptr% f ) {}

Meaning, you can pass a 'void_func_ptr^' type but not a 'void_func_ptr%'
type? Then I can see your point, since it should be able to convert any '%'
type to a '^' type and go that way. Except, then this would not allow you to
overload these two calls differently (which could be the reason it's not
done, but what the heck do I know)...

My 2 cents...

[==P==]

"Holger Grund" <ho**********@remove.ix-n.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Arnaud Debaene" <ad******@club-internet.fr> wrote

I can understand why delegates and arrays are special from a FE
perspective (even though, I strongly believe it's another design
flaw), but what the heck is special about System::String?

Well, while you're at it, I'll appreciate if you could share your
understanding on the reasons for the limitations on arrays and delegates
too ;-)

I didn't say I like it ;-) But obviously, there's some compiler magic
involved
with arrays and delegates. For instance, the CLR doesn't expose arrays
as specialiazations of ::cli::array<> as in C++/CLI. But there isn't
something
obviously different for String. IIRC it has a special short form at
encoding
level and there are probably some subtleties involving string literal
conversions.

If you ask why a user should care about it, I don't know. In fact, I think
I filed a bug for the delegate case, which was closed as by design.

Yes, there it is:

http://lab.msdn.microsoft.com/Produc...d-f1595d7d7e45

-hg