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

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Holger Grund - 15 Nov 2005 17:09 GMT

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

Reply to this Message

Nishant Sivakumar - 15 Nov 2005 17:55 GMT

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.

Signature

Regards,
Nish [VC++ MVP]

> What's special about System::String?
>
[quoted text clipped - 18 lines]
>
> -hg

Reply to this Message

Holger Grund - 15 Nov 2005 18:19 GMT

> 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

Reply to this Message

Nishant Sivakumar - 15 Nov 2005 18:27 GMT

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.

Signature

Regards,
Nish [VC++ MVP]

>> 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.
[quoted text clipped - 14 lines]
>
> -hg

Reply to this Message

Holger Grund - 15 Nov 2005 18:38 GMT

> 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
[quoted text clipped - 6 lines]
> 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

Reply to this Message

Arnaud Debaene - 15 Nov 2005 19:10 GMT

> 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

Reply to this Message

Holger Grund - 15 Nov 2005 21:30 GMT

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

-hg

Reply to this Message

Peter Oliphant - 15 Nov 2005 23:56 GMT

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==]

>>> I can understand why delegates and arrays are special from a FE
>>> perspective (even though, I strongly believe it's another design
[quoted text clipped - 21 lines]
>
> -hg

Reply to this Message

Rate this thread:

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

Free Magazines