Re: Is MSDN wrong? or I made a mistake? about static member function

One of the other intersting confusions is about whether or not CStrings exist on the
stack. There was even a recent exchange here where someone suggested that an alternative
solution would be to use a smart pointer, "if you didn't mind the fact that data was on
the heap" or some such reference. Apparently missing the fact that for CString, CArray,
std;:vector, etc., the data is actually on the heap anyway!

It is also worth pointing out that most people are content writing
a[i]
without being overly concerned whether the declaration was
int a[200];
or
int * a = new int[200];
so the fixation that the use of . and -> have meaning seems a bit far-fetched.
joe
On Wed, 12 Jul 2006 11:12:57 -0400, Joseph M. Newcomer <newcomer@xxxxxxxxxxxx> wrote:

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.

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.

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.
joe
On Wed, 12 Jul 2006 02:09:08 GMT, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:ub06b2d78b2ssp2sqhgm24f1n7v04m2muk@xxxxxxxxxx
After real data types were implemented, it was clear that
struct S1 p1;
had a specific meaning and the construct
p1->x;
was complete nonsense (a K&R compiler of the 1970s would have compiled
this and generated
erroneous code), so this is now diagnosed as a syntax error. Similarly,
struct S1 * p1;
p1.x;
was also complete nonsense, and is also an error. Therefore, there is
little, if any,
reason to maintain such bizarre notations. Since I've worked in languages
which were
designed, rather than thrown together, we used just one notation, and the
compiler was
smart enough to figure out what to do. Since there is also no need to
worry, at a
programming level, as to whether or not a heap object or stack/static
object is being
referenced, the whole "."/"->" notation should be abandoned. Languages
like C# and Java
have abandoned it.


On the contrary, p1->x makes it easy to see p1 was allocated on the heap and
needs to be deleted or otherwise memory managed. p1.x does not.

C# further compounds the confusion by having some rule for allocating some
objects on the stack, and some on the heap, and it is not apparent where
your object is. It is necessary to know for deterministic finalization,
something else C# is weak in.

I couldn't care less what the history of the language is, but I find like
the two distinct notations: -> and .


In the case of static members, as already pointed out, static methods are
referenced by
classname.method rather than variable.reference.

Yeah, and in unfamiliar code, sometimes it's not obvious what is the
classname and what is the instance name. Especially in languages like C#
which discourage Hungarian notation! And also it forces you to define the
method within the declaration, so of course the method declaration doesn't
have classname::methodname in it, so you don't see the classname there
either.

-- David


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: GNAT GPL for Mac OSX stack checking problem
    ... The compiler and GPS seem to work, it is the generated test driver ... documentation to increase it under macos, but traditionally, the stack ... Linux GNAT uses the heap, Rational Apex uses the heap, the VADs Ada83 ... The above test driver would not have run on older Linux releases using ...
    (comp.lang.ada)
  • Re: Value Types and Reference Types
    ... There is a stack and a heap. ... The compiler basically has a list of types that are ... If you do int x and then object y = x. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: GNAT GPL for Mac OSX stack checking problem
    ... >> The compiler and GPS seem to work, it is the generated test driver ... >> documentation to increase it under macos, but traditionally, the stack ... >> Linux GNAT uses the heap, Rational Apex uses the heap, the VADs Ada83 ...
    (comp.lang.ada)
  • Re: Off Topic: Stack vs. Heap
    ... >> If heap or stack implementation is not part of the standard, ... > It depends upon your compiler. ... Kevin Grigorenko ...
    (comp.lang.cpp)
  • Re: C# syntax as an option in Delphi w32
    ... monitor the Objects lifecycle. ... Each native executable has it's own heap manager, ... which are the main reason why a C++ compiler has to ... faster than heap allocations in native applications and you the GC heap ...
    (borland.public.delphi.non-technical)