Re: Is MSDN wrong? or I made a mistake? about static member function
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:sl3ab21ljjjcsmb13u9636ugusim9c9hfe@4ax.com...
But you are assuming that it should matter that the programmer know a heap
object from a
local object by the way the accessor is written. Given the huge number of
languages that
have existed (some since the early 1970s) in which this was never an issue
to worry about,
I find the fixation about worrying about heap objects in C rather
surprising. Why
shouldn't we have a uniform notation? You can tell a heap object from a
stack object by
its declaration! This sounds like the argument that reference variables
in C++ are evil
because they are really pointers, but don't look like them, so the
programmer becomes
confused. I've only used two languages (three if you think of C++ being
different from C)
in which there was a special notation for accessing
values-vs-pointers-to-values. VB
programmers work perfectly well with REF variables without insisting that
a "*" should be
used to dereference them; Pascal and Algol are key historical languages
that didn't need
to distinguish ref parameters, and most purists agree that the .^ notation
of Pascal was
the result of trying to build a compiler on a tiny computer by someone who
wasn't a very
good compiler writer. So I don't see the emotional attachment to . vs ->
as actually
having any basis except the historical accident.
All things considered, it's a small point. I'm getting tired of debating
small points. My inital view (and it still hasn't changed) is that pointers
and values are two separate things and should be accessed differently.
That's all. The fact that in addition to not distinguishing them very well,
..NET also takes control away from you of whether your object is allocated on
the stack or on the heap (with "new"). As I've said that makes a difference
in how the object allocates members.
The deterministic destructor problem is intrinsic to C#, and is a real
pain, but knowing
heap instances from stack instances doesn't solve the key problem, and
seeing a -> vs a .
will not help either.
Yes, as I've said previously.
And what's wrong with discouraging Hungarian notation? It was at best a
crutch, at worst
completely misleading. If it doesn't exist, guess what, you're FORCED to
find out the
truth by looking at the declaration.
In many years of programming I've never had a failure that HN would have
saved me from.
Compilers catch such errors; the reason HN was developed was that the
compilers of its era
*couldn't* catch the errors, because there was no cross-module type
checking (no
prototypes in pre-ANSI C). In any case, the use of HN in WIndows is a
perversion of the
original goal, which was to represent logical types, not machine
representation.
Good IDE's which can tell you the type of things with Intellisense and
tooltips do in a large part negate the need for HN. But HN has just become
a natural extension of programming for me and helps me be more efficient.
It's how I think.
I've always thought Pascal had it backwards to make you say:
var
i : integer
because it puts the name as more important than the type. It's more natural
as a developer to say, hey, I need an integer, what should I call it?
int ?? Ah,
int nTickCount;
Since I've already thought of the type, naming it in HN is second nature.
-- David