Re: List<> of struct with property. Cannot change value of property. why?

Yes, it could. The compiler knows, at least to some degree, that a
method changes the struct that owns it.

I'm not sure why you say that. As it's compiling the method, it's true
that information is present. But outside of that case, how would the
compiler know the method changes the struct?

The same way C++ deals with const methods.

Should it flag all methods
that change a struct somehow, and cache that information somewhere for use
when compiling other code?

Yes, but it would seem less silly if there were more reasons to use
such information. And having "const" is a large one.

Should the linker be required to carry this
flag around too, so that when you import a reference to a struct type not
compiled with the current project, you still have that information?

I have no idea, but I would assume that a C++ linker does. After all,
it's just one bit.

This is a similar issue to
C#'s lack of 'const' for variables and methods. If it had the
internal features that checked such things, then it'd know.

I don't see it as "similar". I see it as identical. :)

:)

If C# had "const" for variables and methods, then it would also have the
function name decoration that's used to convey that information that
C++ has. Then when compiling code that uses a method, *if* the "const"
keyword were used, it could know that the method doesn't change the struct.

Yup.

But then what is the compiler supposed to do with methods not marked as
"const"? Should it automatically assume that the method *does* change the
struct?

In c++, if you have a method that doesn't change it, but you don't
tell it specifically that it doesn't change it, then the compiler
assumes that it COULD change it, and thus doesn't trust that it's
being nice. So, it's not that it assumes it does change it, it just
assumes that it could change it. And if that's an issue, which it is
for a method called on a temporary copy (are these called
'temporaries'?), then the compiler could say, hey, since you didn't
say you won't modify this struct, it means you may modify it, and if
you do, you're not going to get what you expect. Just a friendly
warning.

And in that case, should the compiler instead of copying the
value type create some sort of hidden reference to it on which the method
can operate? And if so, why shouldn't the compiler just always do that?

No, it shouldn't do your work for you. It's just there to notify you
when you're being stupid.

IMHO, C# is only "not quite complete" in the same way that C++ and BASIC
and FORTRAN are all "not quite complete".

I agree.

More specifically, it seems to me that C# has pretty well decided what
value types are going to do and not do, and it's pretty clear that you
don't get to have references to value types. Given the lack of references
to value types, I don't see any clean way to have a List<> return a
reference to a value type within the list for some method to operate on.

I am still programming in C++ mode. It's taking me a while to realize
that structs become more useless when the language is built mainly
around reference types.

I never had troubles with Lists in C++ like
this.

You would have if there were any implementations of lists in C++ that
provided access to list items by value. There may in fact be such an
implementation, and if there is, it will have the same issue. It will
return a copy of a value within the list, and you can operate on that copy
'till the cows come home and the item in the list will never change.

I was referring to the STL, which is part of the (or at least the
defacto) standard. It was put together surprisingly well.

I wouldn't agree that the designers want you to use reference types when
you can. There's a time and place for a value type, and in fact they even
have their place in lists. But it seems to me that other than some
semantic oddities (that I've complained about myself :) ), the basic
behavior is well-defined.

I guess at the moment I decided to have a method in my struct, I
should have moved to a class.

I agree that this particular example is somewhat confusing. In the same
way that overloading the "new" operator bugs me about reference types
versus value types, you're dealing with a situation in which the indexing
operator "[]" behaves differently depending on whether you've got an array
or a List<>. With an array, you get the actual item in the array. With a
List<> you get the value from the array, which is always a copy of the
item in the array (and if it's a copy of the reference then you can still
directly act upon the instance referenced). But once you understand this
difference, the underyling "reference vs value" behavior is consistent and
reliable.

Yup. thanks for your comments, Pete

Zytan

.

Relevant Pages

  • Re: List<> of struct with property. Cannot change value of property. why?
    ... method changes the struct that owns it. ... how would the compiler know the method changes the struct? ... Should the linker be required to carry this flag around too, so that when you import a reference to a struct type not compiled with the current project, you still have that information? ... There's a time and place for a value type, and in fact they even have their place in lists. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: About reference
    ... > I got more confused regarding the size of a reference. ... > char c; ... In struct A there is no reference involved :-) ... It means there are situations where the compiler can do the substitution ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Order of evaluation.
    ... >> I think you might want to run this one by your compiler before you get ... > Took me ages to find that reference. ... because in C a struct definition does not create a new ... a.c.l.l.c-c++ FAQ mirror: http://www.inglorion.com/acllcc++.html ...
    (alt.comp.lang.learn.c-cpp)
  • Re: not null
    ... object corresponding to null does not fulfill the contract: ... Whether you replace null with a reference to some fake object would change ... The compiler gives you an error when you call ... Statically it is does not go, unless lists are ...
    (comp.lang.ada)
  • Re: null terminated strings
    ... parse the /LIST output of the compiler, and report on variables that are referenced only once. ... lists, for each variable referenced in the procedure, the line ... A utility can check the cross reference, and when a variable has only one reference, it's time for a look at that section of code. ... Also, nearby in the cross reference may be another variable with similar spelling, and that's an indicator that perhaps there is a typo. ...
    (comp.os.vms)
Loading