🚀 go-pugleaf

According to jimad@microsoft.UUCP (Jim ADCOCK):
>The reason to make ["operator new" and "operator delete"] "really special"
>[is] that implementations can reasonably be expected to exist that don't
>use normal function calls for implementing such things.

Any such implementation is free to create a wrapper when the
programmer requests such a function's address.  This solution would
simplify the programming model by making all functions addressable.
But, in truth, the issue of function addressing is relatively minor; I
don't think any programmer would resent "void *op_new(size_t n)".

>If you do not _insist_ on _doing_ such pointer conversions, then there is
>no reason to _require_ all C++ compilers to support them.

My only point all this time has been that the ARM, *right now*,
basically requires that |T*| to |void*| conversion be reversible.
Note that I take no sides on whether that requirement is a Good Thing
or not.  Nevertheless, what the ARM guarantees, I will use.

>According to chip@tct.uucp (Chip Salzenberg):
>|As has been mentioned before, ANSI C requires that |void*| and |char*|
>|have the same representation.  If ANSI C++ does not conform to this
>|requirement, then compatibility with C libraries is compromised.
>
>This is rightly a quality-of-implementation issue.

It is only a QOI issue if the ANSI committee punts.  They may yet take
a firm stand.  Reports of the death of C compatibility as an ANSI C++
issue are greatly exaggerated.

>What does it mean to the ANSI-C *Language* to say that void*'s and char*'s
>have the "same representation" ???  I claim: nothing.

Actually, it has a very important meaning: In the absence of function
prototypes, a formal parameter and an actual parameter are considered
to be correctly typed even if one is |void*| and the other is |char*|.
For example, this program is guaranteed to work under ANSI C:

   f1.c:

      main()
      {
          blah("howdy");
      }

   f2.c:

      #include <stdio.h>
      blah(void *p)
      {
          puts(p);
      }

See?  It *is* a language issue, after all.

>I claim it means nothing to the C++ *Language* to say that member
>addresses within a labeled section must have ordered addresses ...

Well, that guarantee can also be used.  An example using offsetof()
comes to mind; however, it is too contrived for me to post without
embarassment.  [:-}]  But, that is a fight for another day.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "Most of my code is written by myself.  That is why so little gets done."
                 -- Herman "HLLs will never fly" Rubin