Article View: comp.std.c++
Article #52Re: New operators wish list
From: W.R. Volz
Date: Tue, 21 Jul 1992 16:18
Date: Tue, 21 Jul 1992 16:18
80 lines
3630 bytes
3630 bytes
In article <658@manutius.UUCP>, garyp@manutius.UUCP (Gary Powell) writes: |> Ok, Ok Ok...lets cut the relgion and get to the meat of the matter. |> |> It appears to me that there are a large number of folks who want the following |> new operators added to the language. |> |> 1) ||= |> |> where: x ||= y <==> x = x || y |> |> Seems resonable as it matches all the "Blah"= operators. |> |> 2) &&= |> |> where: x &&= y <==> x = x && y |> |> Also seems reasonable for the same issue as #1. |> |> |> 3) === |> |> where x === y <==> x = x == y |> |> I have more trouble looking at this one, but again it still fits the |> "blah"= operator rule. So it maybe that I just haven't thought about |> it long enough. Anyway I recommend it. |> |> 4) some set of chars yet to be determined which bind tighter than the * and / |> for which x power y is x raised to the power of y. |> |> This seems reasonable but again has the problem of what do we do with |> the odd ball arguments of y and x? |> |> I recommend we define it as an operator but leave its implementation alone |> and let everyone overload it as they see fit. And I don't care which |> set or single character is chosen. My reasoning is that the current |> arguments don't seem to be converging. Maybe someone else (I'm sure I'll |> see heat on this one.) would care to summarize the arguments on this. |> |> 5) "." |> Lets add this. I mean really, no one's code will break if we have it, |> the earth will not shake and the sky fall down. If it turns out to be |> not as useful as Jim claims..so what? We'll drop it from language "D" |> the next generation. |> |> Any others I've missed??? |> |> Lets get on with it. Like it or not many of us have to work with C++ even |> though language "X" is better at some other task. Lets add the features folks |> clamor for. IF they can make a convincing statement of "It won't break any |> existing code. And it is possible for someone of resonable experience |> programming to use it without shooting themselves in the foot." |> |> We still have a lot of other pressing problems, like how to incorporate |> persistance, and how to do good garbage collection, and how to at run time |> create objects whose type isn't known until after the program is running. |> |> |> BTW. |> Could you folks who want to argue language issues move your discussion over |> to this group? Then we can quit annoying the folks who want to compare |> Borland to Mircosoft or ask the beginners questions. And I don't have |> to read 100 or more messages to find the language issue ones. |> Whoa. All of these are simply programmer convienences (sp?). I would rather code a few more characters and be able to clearly read the code than save a few bytes of disk space. If that many new operators are going to be added, why not just make it a rule for all binary operators? .i.e, x (op)= y; <==> x = x (op) y; -- ====================== Bill Volz Chevron Oil Field Research Co. Exploration Research/Geophysics Division. P.O. Box 446, La Habra, CA 90633-0446 Phone: (310) 694-9340
Technical Details
Message-ID:
<5248@lhdsy1.lahabra.chevron.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!lhdsy1!kato.lahabra.chevron.com!hwrvoReferences:
<658@manutius.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!lhdsy1!kato.lahabra.chevron.com!hwrvo From: hwrvo@kato.lahabra.chevron.com (W.R. Volz) Newsgroups: comp.std.c++ Subject: Re: New operators wish list Message-ID: <5248@lhdsy1.lahabra.chevron.com> Date: 21 Jul 92 16:18:10 GMT References: <658@manutius.UUCP> Sender: news@lhdsy1.lahabra.chevron.com Organization: Chevron Oil Field Research Company Lines: 80