Re: csharp language idea

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

cody <deutronium@xxxxxx> wrote:
Yes, it should be - it shows that they've changed the semantics in an
incompatible way. Changing something from a class to a struct can break
lots and lots of behaviour - the *good* thing about this is that you
get told about it at compile-time, instead of things just breaking!

Maybe, a think the problem connected with value types cannot be solved
without making drawbacks.
I think the CLR team had a hard time, not how to do it perfectly, but solve
ther problem it the best possible way.

I don't know about "the best possible way" but they've done pretty
well. (I'm not saying I would necessarily be able to make it better
myself - I'm just cautious about ruling out the possibility of better
ideas!)

What would be wrong with that? You'd just have methods like you have on
DateTime, which return a new DateTime instead. Unless those structs are
huge (in which case they probably shouldn't be structs in the first
place) that shouldn't be a problem.

a matrix consist of 4x4 floats, making them at least 64 byte in size.
Vertices like PositionnormalTextured are 3*4+4*4+2*4 bytes in size, if
loading big models from a file consisting of 100.000 vertices it makes a
difference imo.

Well, if you're using a value type for performance reasons rather than
semantic reasons, you've already made a design trade-off. When you're
further bending good design practice (which IMO includes making structs
immutable) I think it's reasonable that the compiler makes it slightly
harder to do things. I think that's better than the compiler making it
easy to go behind your back, calling setters which aren't *obviously*
being called in your source.

I can't remember all of them off-hand, but there are some really weird
ones. I've been reading through the C# 2.0 specification, and there are
some places where mutable structs behave in ways you really need to
read the specification *very* closely to understand.

could you please try and remember now Iam very tense :)

Well, this isn't a *brilliant* example, but it's a start. I wish I
could remember the others.

You know if you have a value type in an ArrayList (not a List<T>) you
have to get it out, change it, and then put it back in order to change
the value, right?

Well, not quite.

Suppose the value type implements an interface which allows mutation.
That interface is implemented by the boxed version as well as the
unboxed version, so can change things in-place, in the box. Here's an
example:

using System;
using System.Collections;

interface IMutable
{
int X { get; set; }
}

struct MutableStruct : IMutable
{
int x;

public int X
{
get { return x; }
set { x = value; }
}
}

class Test
{
static void Main()
{
IList list = new ArrayList();

MutableStruct original = new MutableStruct();
original.X=5;

list.Add(original);

// Compiler disallows this
// ((MutableStruct)list[0]).X = 10;

// But this is fine
((IMutable)list[0]).X = 10;

MutableStruct mutated = (MutableStruct) list[0];
Console.WriteLine (mutated.X);
}
}

It makes sense, but it's slightly unnerving at the same time.

(Out of interest, did you know you could assign to "this" in a struct?
It certainly took me by surprise when I was reading the spec recently.)

a funny thing, but a good feature.

I think we'll have to disagree.

Why not? Remember the "this" in a value type is not a pointer like it is in
a class but a value passed by reference.

Exactly - but that difference is rarely particularly visible, so it
comes as a surprise when you see this syntax for the first time.

So we can change it. How else would you program a method which makes a
copy of a given struct without copying each field separately?

To be honest, I'd copy each field separately if this feature weren't
available. If you're following the normal design guidelines for
structs, there are rarely many fields anyway.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Types in C
    ... Structs and unions are user-defined. ... definitions without direct compiler support. ... be portable to compilers that don't have inline functions". ...
    (comp.lang.c)
  • Re: Dynamically load a dll and us it (in a rexx dll)
    ... The available API functions are dependent on the ODBC version ... The default is usually compiler dependent. ... Depending on the data types used in the structs you ... leave .dll out, it just mentioned path. ...
    (comp.os.os2.programmer.misc)
  • Re: Byte aligned structs
    ... 'data packet' via the serial port. ... structs - i get framing errors for alignment when i apply structs on ... How can i get the compiler to byte align rather than word align. ... routines or macros to insert the shorts and integers for writing and to ...
    (comp.sys.acorn.programmer)
  • Re: Hiring Advice
    ... Use pointers where pointers are appropriate. ... Use structs where structs are appropriate - based on the logic of the program. ... compiler pick the best implementation. ... But I object to making an illogical mix in a struct just to generate smaller code, and I certainly object to calling that mix "clear" programming. ...
    (comp.arch.embedded)
  • Re: About casts (and pointers)
    ... > I believe that whether or not the compiler can deduce that no function ... > The C standard makes guarantees about program execution, ... > about the representations of compatible types (of structs) in ... The C Standard gives a guarantee that under certain circumstances ...
    (comp.lang.c)