Subject: Dereference by XOR?

From: omer mussaev <[email-masked]>
Date: Fri, 29 Oct 2004 13:02:18 -0700 (PDT)

According to MSDN, new release of C++ compiler be
extended with new syntax. MSDN refers to the new
syntax as C++/CLI and mentions that it undergoes
standartization efforts.

The new syntax will introduce (among other things) the

caret operator ("^") in place of asterisk operator
("*") 
for pointer dereferencing. 
New syntax will refer to handles to 
garbage-collected memory, while the old syntax will 
refer to pointers by user-managed memory.

More on the topic can be found on MSDN page:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx

I wonder whether these extensions will be supported 
by Mono framework and by gcc compiler as well.

I assume I will have a tough time recognized a
language 
I like in near future...

=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: guy keren <[email-masked]>
Date: Sat, 30 Oct 2004 01:56:44 +0200 (IST)

> syntax as C++/CLI and mentions that it undergoes

whose standard exactly?

> for pointer dereferencing.

not "in place of", but rather "in addition to".

> by Mono framework and by gcc compiler as well.

and why would gcc support them? mono might, because it aims to copy '.net'
- but the fact that microsoft is doing its bad old game (embrace and
extend until full incompatibility is achieved) does not mean anyone should
jump on the bandwagon. and i didn't hear about gcc supporting '.net',
'cli' or similar things - or is it?

-- 
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

---

From: Ori Idan <[email-masked]>
Date: Sat, 30 Oct 2004 09:50:05 +0200

>for pointer dereferencing. 
And what will be next? replace { and } with BEGIN and END?  :-)

--

Ori Idan

---

From: Muli Ben-Yehuda <[email-masked]>
Date: Sat, 30 Oct 2004 10:17:08 +0200

> > syntax as C++/CLI and mentions that it undergoes

Actually, the last time I read C/C++ User's Journal, it seemed from
the "standartization reports" that half of the various C++ standards
committees are now employed by MS. It certainly helps to have deep
pockets.

> 'cli' or similar things - or is it?

If it will be a standard extension to C++, g++ might well support
it. I don't know, I've stopped reading CUJ. 

Cheers, 
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

---

From: omer mussaev <[email-masked]>
Date: Sat, 30 Oct 2004 03:52:23 -0700 (PDT)

> > syntax as C++/CLI and mentions that it undergoes

They had mentioned ECMA - the body that had 
standartized JavaScript.

> not "in place of", but rather "in addition to".

Both.

Pointers to managed memory are promised to be 
introduced "in addition to" the pointers to machine
memory.

Syntax of pointers to managed memory will, however, 
use "^" operator - "in place of" "*" operator - that 
will remain in service.

=====
--
o.m.

---

From: omer mussaev <[email-masked]>
Date: Sat, 30 Oct 2004 04:00:04 -0700 (PDT)

--- Muli Ben-Yehuda <[email-masked]> wrote:

[ discussion on why gcc should not have proprietary 
  extenstions to c++ ]

> it. I don't know, I've stopped reading CUJ. 

According to
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf

this might be part of C++ standard as well..

> ATTACHMENT part 2 application/pgp-signature
name=signature.asc

=====
--
o.m.

---

From: Oleg Goldshmidt <[email-masked]>
Date: 30 Oct 2004 14:24:16 +0000

> syntax as C++/CLI and mentions that it undergoes

Huh, I was surprised to learn that CLI was "Common Langiage
Interface". I thought it was some other interface... ;-)

> refer to pointers by user-managed memory.

I suppose they can avoid confusion with the binary XOR - this will
always be unary - just like the dereference asterisk is not confused
with multiplication. However, I wonder how I can use this extension
while keeping the application both portable and spaghetti-free.  While
other GC-related stuff such as "gcnew" can be preprocessed carets
cannot.

> I assume I will have a tough time recognized a language I like in
> near future...

"I don't know what the language will look like in 50 years but it will
be called Fortran"?

It is not necessarily a bad thing - that is how language standards
evolve: vendors introduce extensions, some of these prove useful, are
implemented by other vendors, and get into standards. Hopefully,
patenting such things will be counter-productive because vendors are
usually interested in getting their stuff into standards.

Does anyone else find this sentence:

"Second, a new version of the C-runtime library (CRT) with enhanced
security features will be released with Visual C++ 2005. As part of
Microsoft's ongoing commitment to the Trustworthy Computing
initiative, this release of the CRT will help increase the collective
security of applications that integrate the CRT."

amusing? [My interpretation: "our current implementation of C has
buffer oveflows and other holes all over the place..."]

-- 
Oleg Goldshmidt | [email-masked]

---

From: Adi Stav <[email-masked]>
Date: Tue, 2 Nov 2004 00:34:27 +0200

> And what will be next? replace { and } with BEGIN and END?  :-)

Why, the feature looks quite nice to me.  But C++ is not my forte.
Would one of the C++ gurus on the list please detail why this is a good
or bad idea?  Also, if this gcnew keyword has been around for a while,
why is ^ needed at all?

(At first I thought this refered to the nasty double-list pointer XORing 
trick, which is also -- what a coincidence -- a deadly cocktail when
mixed with GC.)

-- OT extra=flamebait --
Also, guys, this needs to be said: YAHOO GROUPS IS A SMELLY, STUTTERING,
DRUNKEN, SCHIZOPHRENIC PIECE OF SO-CALLED WEB SERVICE THAT IS NO MORE 
CAPABLE OF GIVING REASONABLE SERVICE TO A MANNED BROWSER THAN I AM CAPABLE 
OF INTERSTELLAR FLIGHT IN MY PAJAMAS.  I just spent the better part of an 
hour (north of 40 minutes) getting it to recognize and agree to receive 
emails from me to hackers-il sent from an address different from the one 
with which we have been initially formally introduced. It was a painful, 
technokafkaesque process that involved at least four Web forms, typing my 
password no less than eight (8) times, receiving three confirmation emails, 
creating an deleting a new account, typing my new email address twice, 
and at one time hand-editing a broken 404ing URL (admittedly, I use Firefox, 
but I think they claim to support this one).  For those bored enough to 
notice, the reason why I haven't written in some two years or so is that 
every time I tried to mail the group I was kindly reminded by a user friendly 
bounce email that my new address was not registered, and I always gave up 
after 15 minutes in their HTML labyrinth. This is the first I actually force 
myself to sit through it until it works. And I am not exactly computer 
illiterate, you know. If Yahoo Groups makes it through 2005, I'll be 
astounded.
-- /OT --

---

From: Gadi Evron <[email-masked]>
Date: Tue, 02 Nov 2004 09:32:40 +0200

> Why, the feature looks quite nice to me.

I have to admit that regardless of this being good, or bad - it reminds 
me of high-school and Turbo Pascal. Not a pretty sight.

---

From: omer mussaev <[email-masked]>
Date: Tue, 2 Nov 2004 00:25:48 -0800 (PST)

> or bad idea?  Also, if this gcnew keyword has been

This is a bad implementation of a good idea.

Handles (this what MS calls to the things which you
can dereference and get gc-controlled areas) have 
quite different semantics from pointer. 

For starters - value of a handle may change while 
preserving the identity of an object it points to. 
This's because the gc has all the rights to 
rearrange the memory it controls. This eventually 
defines all handles as "volatile".

In addition: pointer arithmetic between handles ("gc
pointers") and plain old pointers is meaningless.
The idea is good because it allows the programmer 
to define explicitly what semantics apply for the 
handle. For example, the compiler can catch meek 
attempts to "delete" the handle to gc area and comply
loudly.

The long list of semantic differences between gc 
memory and plain memory can be continued, and making
the developer define gc memory as such certainly makes
life of a compiler easier.

On the other side, there exists "prior art" of making
the compiler understand the semantic differences 
between different kinds of pointers using metalanguage

tools and approaches[0,1,2]. This makes me think MS
could do better job. 
 
> -- OT extra=flamebait --
[removed]

References:

[0] - MC++D, 
      Andrei Alexandrescu
[1] - "Generative Programming - 
       tools methods and applications", 
       Czarnesky et al.
[2] - "C++ for Real Programmers", 
       Jeff Alger

=====
--
o.m.

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: [email-masked]
Date: Tue, 2 Nov 2004 13:31:52 +0200

> me of high-school and Turbo Pascal. Not a pretty sight.

With all of its problems, Pascal has gotten one thing right: a post-order
dereference operator (not that this suggested feature fixes it). C has p[0], of
course, but it's not a pretty sight, either. 

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: omer mussaev <[email-masked]>
Date: Tue, 2 Nov 2004 04:20:57 -0800 (PST)

Pardon my ignorance, but what's post-order dereference
operator and how is it different from dereference
using
asterisk operator?

=====
--
o.m.

---

From: [email-masked]
Date: Tue, 2 Nov 2004 14:35:20 +0200

> operator and how is it different from dereference

It isn't. It's just a different syntax. In Pascal you do "p^: where in C you
would "*p". In C, almost any dereference that is part of a larger expression
needs to be parenthesized. This is why K&R added the -> hack, which solved only
part of the inconvenience. In Pascal you simply do "p^.member".

---

From: Ori Idan <[email-masked]>
Date: Tue, 02 Nov 2004 16:21:39 +0200

>buffer oveflows and other holes all over the place..."]
I would say it means: "In the next version of C-runtime library you will 
not be able to run or write software that we don't want you to".

--

Ori Idan