anti-aliasing

[Malcolm McLean]

A proposed new function

int alias(void *ptr1, size_t len1, void *ptr1, size_t len2)

Returns true if the pointers overlap.

On most machines it can be trivially implemented. However it has to be a
standard library function because it is not necessarily legal to compare two
address from different objects.

The advantages:

An unintelligent implementation simply executes the user's error-handling
code if an unwanted alias is passed. An intelligent implementation can
detect that the two pointers cannot possibly be aliases, and generate moe
efficient code.

However the restrictions do not percolate up to calling code. There is no
need to declare every pointer parameter "restict" just because somewhere you
call a library string copy.

[Arthur J. O'Dwyer]

On Sun, 18 Feb 2007, Keith Thompson wrote:

"Arthur J. O'Dwyer" <aj*******@andrew.cmu.eduwrites:

>On Sat, 18 Feb 2007, Mark L Pappin wrote:

>>>
IMnaaHO, they should have kept the underscores and added a new header,

[...snip...]

> I agree that that is definitely the Right Thing. However, something
that might be more user-friendly, and is /almost/ as right, is the
following approach which I have seen used in the real world:

[...snip...]

There's another approach (already mentioned in this thread) that's
just as user-friendly *and* standard-compliant. Add "__newkeyword" as
a keyword, and add "#define newkeyword __newkeyword" in a new
<newfeature.hheader.

I agree that that is definitely the Right Thing. However, something
that might be more user-friendly, and is /almost/ as right, is the
preceding (snipped) approach which I have seen used in the real world.

-Arthur,
see previous post for the details and caveats

[P.J. Plauger]

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:j_******************************@bt.com...

"P.J. Plauger" <pj*@dinkumware.comwrote in message >>Therefore the
underscores had to come out.

>>
Out of curiosity, what was the compiler and what were the keywords?
The only case I know of in recent memory is managed VC++ with its
gcnew keyword.

Did you ever wonder why the Managed Extensions have all those ugly
underbar keywords like __gc and __value? Because the Managed Extensions
religiously follow the C++ standard, which says, "If thou really must
introduce new keywords, thou shalt name them beginning with double
underscore!" But guess what? When Microsoft introduced __gc, __value and
the rest, the Redmondtonians received "unexpectedly strong" complaints
from programmers. Yeah! Programmers of the world, unite! You have nothing
to lose but your underbars. Underbars make your code look icky, like some
kind of assembly language program or something. So C++/CLI has ref and
value, sans underscores. This meant adding new keywords to C++, but so
what?

Uh, no it doesn't. See below.

As Bjarne
says, "My experience is that people are addicted to keywords for
introducing concepts to the point where a concept that doesn't have its
own keyword is surprisingly hard to teach. This effect is more important
and deep-rooted than people's vocally expressed dislike for new keywords."
(True, true. I love that Bjarne is describing the psychology of
programming.) So C++/CLI ditched the underbars. By making them positional
keywords instead of reserved keywords, they can't conflict with programs
that may already use these words as variable or function names.

Full text:

http://msdn.microsoft.com/msdnmag/is...k/default.aspx

Wait a minute -- you can't have it both ways. Aside from the gcnew I
mentioned, *none* of the alleged keywords Microsoft introduced infringe
on the user name space. So they're not really keywords. And so
Microsoft is actually being a very good citizen with C++/CLI. But all
you said was:

: Therefore the underscores had to come out.

Thus encouraging Mark L. Pappin to opine:

: They deserve condemnation for polluting the user's namespace.

Truth to tell, I have never seen a cleaner dialect of C or C++
introduced over the past third of a century. In fact, I had to
disable the namespace-purity tests in our validation suite over
a decade ago because I can't find an implementation of either
language that even tries to honor the full requirements of the
C and/or C++ Standards. (And I'm the guy who fought for, and
won, the separation of name spaces in both standards.)

Every Unix/Linux/*ix has its complement of open/close/read/write
/seek/etc. Try redefining any of these as an external symbol and
your executable will probably blow sky high. Every commercial
compiler drags a tail decades long of additions that no vendor
dares remove, lest they alienate their installed base. The
Dinkumware library can be configured to be namespace pure, but
we haven't had an OEM ask us to do so for more years than I can
count. Keywords, macros, and external symbols not reserved to
the implementation are all violations of the Standards contract,
and they're all ubiquitous.

So here we have a case of Microsoft doing a *better* job of
honoring the C and C++ Standards than anybody else and what do
they get? An undeserved trashing. Mind you, I'm not saying that
the folks in Redmond have never been above reproach, but when
they do something right they deserve to be recognized for it,
not savaged with misinformation.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Servé Laurijssen]

"Serve Laurijssen" <se*@n.tkwrote in message
news:er**********@news6.zwoll1.ov.home.nl...

>>memmove()
memcpy()
memmove()
memcpy()
memmove()
memcpy()
memmove()
memcpy()

Psychology.

Looks to me the whole "adding a runtime aliasing check function to the C
standard" is not gonna happen :)

[Richard Bos]

"Malcolm McLean" <re*******@btinternet.comwrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message

"Malcolm McLean" <re*******@btinternet.comwrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
If you want the memmove() behaviour, use memmove(), and don't
expect the rest of us to use a slower, and therefore inferior (and yes,
in the case of these functions the difference rather easily _can_ be
significant), memcpy().

The snag is that memmove() is called memmove. Psychology matters. If
memmove() were called memcpy() and memcpy() fast_memcpy(), then matters
would be different.

Bollocks. If your amateur programmer can't be arsed to read his
documentation before using a function called memmove(), that's his
problem, not mine, not the Standard's. I want, and many people need, a
memmove() which DTRT, and TRT for us is _not_ to unnecessarily duplicate
what memcpy() already does perfectly well.

Psychology matters.

Possibly, but psychology is too often abused to mollycoddle people who
should be in another business. If you can't manage to deal with the
difference between memmove() and memcpy() to the extent that you want to
deprive those of us who can of a useful (and indeed sometimes necessary)
resource, you shouldn't be a programmer, you should work in HR instead.

Richard