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]

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

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" <hg@remove.ix-n.net> wrote in message
news:Ofu$LZg6FH A.3880@TK2MSFTN GP12.phx.gbl...[color=blue]
> 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
>[/color]

[Holger Grund]

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

"Nishant Sivakumar" <nish@nospam.as ianetindia.com> wrote
[color=blue]
> 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.
>[/color]
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::Excepti on% );
int main()
{
R r;
System::Excepti on e;
}

-hg

[Nishant Sivakumar]

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

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" <hg@remove.ix-n.net> wrote in message
news:O5h5BDh6FH A.476@TK2MSFTNG P15.phx.gbl...[color=blue]
> "Nishant Sivakumar" <nish@nospam.as ianetindia.com> wrote
>[color=green]
>> 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.
>>[/color]
> 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::Excepti on% );
> int main()
> {
> R r;
> System::Excepti on e;
> }
>
> -hg
>[/color]

[Holger Grund]

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

"Nishant Sivakumar" <nish@nospam.as ianetindia.com> wrote[color=blue]
>
> 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.
>[/color]
Oc, there are readonly instance methods and properties that do not
modify the string.
[color=blue]
> 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[/color]
What's wrong with not creating a dtor or one that does nothing?
[color=blue]
> 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.[/color]

Same here.

-hg

[Arnaud Debaene]

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

Holger Grund wrote:[color=blue]
>
> 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?[/color]
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]

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

"Arnaud Debaene" <adebaene@clu b-internet.fr> wrote[color=blue][color=green]
>>
>> 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?[/color]
> 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 ;-)[/color]

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 specialiazation s 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/ProductFeedback/viewfeedback.aspx?feedbackid=2518bec9-c4ad-4018-9a0d-f1595d7d7e45

-hg

[Peter Oliphant]

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

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(v oid) ;

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" <holger.grund@r emove.ix-n.net> wrote in message
news:%23OIMQti6 FHA.2608@tk2msf tngp13.phx.gbl. ..[color=blue]
> "Arnaud Debaene" <adebaene@clu b-internet.fr> wrote[color=green][color=darkred]
>>>
>>> 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?[/color]
>> 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 ;-)[/color]
>
> 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 specialiazation s 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
>[/color]