Re: c# features

On Fri, 21 Mar 2008 11:00:59 -0700, Ben Voigt [C++ MVP] <rbv@xxxxxxxxxxxxx> wrote:

I thought you were saying that return by reference isn't needed.

No. Well, personally I don't see it as being a big deal. In that sense, I don't really think it's needed.

But no, that's not what I was saying. I was just saying that as C# stands today, it doesn't really provide that functionality.

I'm championing the opposite, that pointers aren't good enough so we need
return by reference.

I agree that pointers aren't good enough to address the question. I don't really think it's strictly necessary to add return by reference.

IMHO it's a philosophical difference, and it's one that I think comes up between you and me on a regular basis. One of the reasons I love C# so much is its simplicity. It's true, there are lots of things you can do in a more "powerful" language like C++ that aren't exactly duplicated in C#. But IMHO you can always achieve basically the same results, and in a much simpler context.

Some engineers like complicated design, some like simple design. I'm in the latter camp, in that I find the simplicity leads to architectures that are easier to design correctly and reliably. IMHO, introducing a "return by reference" semantic would not be in keeping with the existing semantics in C# and would unnecessarily complicate the language.

You obviously disagree, as does the OP. But you are both free to use a different language, one that does support what you'd like to do. Why invest effort in messing up C# for those of us that appreciate its simplicity?

You say, make it a reference type. That's really the
problem, .NET forces you to choose between value and reference semantics in
the type declaration, which is a bad architecture. Maybe 99% of the time
value semantics are desired, placing the object inside its container is
desirable for locality of reference, and it doesn't need to be independently
garbage collected. Seems to me that demands a .NET value type. But now for
the 1% of uses which require return by reference, you're going to change the
behavior of every user of that type.

Well, I disagree with that perspective. There's a fundamental difference between value types and reference types in C#, and this difference is preserved by the current restriction in the language wrt return types, and would not be if methods could return value types "by reference". I disagree that it's bad architecture for the type itself to determine whether value or reference semantics are appropriate.

I'm not going to try to argue that it's _superior_ architecture, but I will vehemently disagree that it's de facto a bad choice for the language. It's simply a design choice, and a valid one at that. You may not like it, but there's no shortage of other languages to choose from in which you aren't so constrained.

[...]
Yes. I don't see anything wrong with that statement. The Win32 API
is a specific API and doesn't take into account garbage collection at
all. In fact, the main reason we have IDisposable and finalizers is
that garbage collection and the Win32 API do not otherwise "get along
with each other".

That's "different", not a conflict.

If there was a conflict, .NET couldn't exist.

I guess that depends on whether you feel the word "conflict" implies lack of resolution. I don't. You seem to.

And, __makeref IS part of the language. It's not part of the international
standard though.

I have no idea what that means. If it's not part of the standard, how is it part of "the language"? I can write a C++ compiler to include whatever non-standard elements I want. Microsoft has in fact done so repeatedly. That doesn't mean those elements are part of "the language". They are just non-standard additions.

Pete
.

Relevant Pages

  • Re: Question on LSP
    ... not have to be explicit attributes, ... Since objects in memory usually don't move, the language can largely hide the identity mapping. ... My issue here is that whatever semantic meta model the language uses, there must be some way for the developer to unambiguously express the OOA/D is-a semantics for some problem space entity. ... Note that the language allows us to use a name like 'T' on the reference as a mnemonic so that the developer can keep track of what is happening with the indirection. ...
    (comp.object)
  • Re: Latest on Windoze Navy software
    ... > If you use a non-portable extension then the behavior of a program ... > that uses that extension is an implementation issue, not a language ... specific implementations which did not impact the language reference, ... > One should distinguish between the semantics of parameter passing ...
    (comp.os.vms)
  • Re: Struct size
    ... reference to base TWO, so I think you still have some work left. ... The C language may have used the notion of 2 in implementation of the ... semantics of unsigned shifts, but I didn't. ...
    (comp.lang.c)
  • Re: The meaning of a = b in object oriented languages
    ... only copying the reference. ... Whether the language is OO or not has no bearing on this question. ... semantics of the assignment operator can and do differ between ...
    (comp.lang.ruby)
  • Re: pass by reference
    ... the reference to an Object by value" refer to the same technical ... Yes, we basically all disagree. ... You can't do one of them in Java, ... In C++, a language where you can do both, the difference is in whether ...
    (comp.lang.java.programmer)
Loading