superdude <me@web1.ucar.edu> wrote in article
<090983616091149CPIMSSMTPU07@email.msn.com>...
>>> 1) "property" - it's present in BCB and VC++ and is de facto widely
accepted. I found it extremely useful. Don't see why it couldn't be added
to
standard. ( and also "closure").

Having just read Stroustrup's "Design and Evolution", I think I have
answered
my own questions on this. __property would likely be (or has been?) judged
a useful but minor syntactic convenience not worth putting in the standard.
Oh
well...

You should also read what he has to say on the subject of generalised
operator
overloading (aside from "Project April Fool").

Arnold the Aardvark
===========================
http://www.foxholly.demon.co.uk
ICQ# 30592054
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[ This is drifting away from C++ standardisation. I am approving
this message, but I will reject any followups. --mod ]

In article <0fb362410191449CPIMSSMTPU07@email.msn.com>,
  superdude <"don't even think about it"@chx400.switch.ch> wrote:

> A new project under the code name "spagghetti" is being intensively
> developed.
That would be an ideal name.

> This is a new language that is not burdened by compatibility issues and the
> most powerful to this date. It's in fact so powerful that we may say that
> it's the last programming language in the history of mankind, because any
> other languge that possibly can be invented is a subset to "spagghetti."
Contradictory. If it's not "burdened by compatibility" then no other
language can be a subset.

Yet another FOWIM (Figure Out What I Mean) attempt. FOWIM was a
hypothetical compiler which would have merged all the rules from
all the "high-level" languages that existed at the time. Therefore
code like this would have been legal:
    for (x=1; x<=25; x+=2) { ' From C
C   Note that comment styles don't have to match language styles
        if (x-10) 5,10,15    -- Fortran
 5      mov y,x;             ' Assembly language
        Y := Y + X*X         /* PASCAL */
 10     PERFORM X-IS-10      ; REM COBOL
 15     printf("X=%d\n", x); // C
    next X                   ' BASIC

It can't work, of course. Not only would this compiler be unbelieveably
complex, but there's simply too many cases where legal code would mean
different things in different languages. The simplest example:

    X = Y = 10;

In C, if X and Y are both int this sets them both to 10. But in
BASIC this sets X to TRUE if Y=10 and FALSE if it doesn't.

> "Spagghetti" allows what we all secretly desired all the time working with
> C++; namely, overloading of all and any operators with arbitrary number of
> arguments and free rules of assigning associativity and precedence so that
> finally we can write the programms in the most natural way.
Yeah, that's what I have always secretly desired. That and higher taxes.

> CIA already approved the language for their top-secret programs.
Oh, Puh-LEEEZ! Some people are seriously suggesting that "The Y2K bug"
(as if there was such a thing) was "planted" by the CIA. It seems
that anything that goes wrong triggers conspiracy theories, and that
every conspiracy theory is somehow tied in to the CIA.

Does the CIA even HAVE top-secret programs? Probably. I'm guessing
that they have three types of top-secret programs: Communications
programs that use very good encryption, programs that analyze and
try to break encryption, and super-secret clones of DOOM and
DUKE3D. It's amazing what you can buy when your budget is labelled
"top secret."

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Thanks everybody for highly valuable input. I'm glad to share with you the
latest information I've received from the sources I have to leave unnamed. A
new project under the code name "spagghetti" is being intensively developed.
This is a new language that is not burdened by compatibility issues and the
most powerful to this date. It's in fact so powerful that we may say that
it's the last programming language in the history of mankind, because any
other languge that possibly can be invented is a subset to "spagghetti."
Right at this time when you're reading this information another independent
company is developing a standard library for "spagghetti" under the name of
"meatballs."
"Spagghetti" allows what we all secretly desired all the time working with
C++; namely, overloading of all and any operators with arbitrary number of
arguments and free rules of assigning associativity and precedence so that
finally we can write the programms in the most natural way. Consider this
example:
class Who_is_the_guy
{
  friend bool operator likes(left: const Who_is_the_guy&, right: const
Tasty_stuff&):
      associativity=left; precedence=1;
};
class Tasty_stuff
{
  friend Tasty_stuff oprerator with( left: const Tasty_stuff&, right: const
Tasty_stuff&):
     associativity=left; precedence=0;
};

Who_is_the_guy Everybody;
Tasty_stuff spagghetti;
Tasty_stuff meatballs;

So now the following code makes a lot of sense:

int main()
{
   return Everybody likes spagghetti with meatballs;
};

CIA already approved the language for their top-secret programs. They are
working now on adapting Mel Brooks scripts for the "spaceballs" project.
May the Schwartz be with you!

G.B.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

superdude wrote:
>
> Hi all,
> Can somebody give me 5 good reasons why the following features are not
> included in the standard.

Isn't one good reason sufficient?

....
> 2) why not to extend operator overoading to any valid identifier (excluding
> reserved keywords). In my engineering applications I feel a shortage of
> standard operators that can be overloaded. I'd like to define something like
> "operator AND_NOT"(that is often not equivalent to ! && chain), etc. and
> possibly operators that accept more than 2 parameters (it's always possible
> to define rules how to deal with ambiguous constructs in this case). Also
> allow some standard operators to be overloaded with different number of
> parameters. For example, I would like to define string operator %(double d)
> { return string(d*100)+string("%");} so that I may write double a = 0.1;
> cout<<a%; and see 10%.
>  It will also allow C++ compiler to perform some functions of
> compiler-compiler. I believe millions of developers will be grateful for
> these features.

And millions more will tear out their hair coping with the problems that
it will cause. Operator overloading already makes it possible to write
C++ programs that look like they're doing something very different from
what they're actually doing. You're suggesting would mean that aeach
program is writting in what is potentially a different language.
Figuring out code written by anyone else who'd actually taken advantage
of this feature could be incredibly confusing. I suspect that it would
make parsing by the compiler a lot more complicated, too.

Use function calls, not operators; it's a little more typing, but other
programmers will actually have a chance of understanding your code
without losing their sanity.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <090983616091149CPIMSSMTPU07@email.msn.com>,
  superdude <"don't even think about it"@chx400.switch.Ch> wrote:

> 2) why not to extend operator overoading to any valid identifier (excluding
> reserved keywords).

Someone (Bjarne) has already suggested generalizing operator overloading.
See
http://www.research.att.com/~bs/whitespace98.pdf
for details. ;-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <090983616091149CPIMSSMTPU07@email.msn.com>, superdude
<me@web1.ucar.edu> writes
>Hi all,
>Can somebody give me 5 good reasons why the following features are not
>included in the standard.

Why 5 reasons?

There are many potentially good ideas that were left out of C++.  Even
so the language is not small.  Every extra feature is another chance to
get it wrong.  One person's most desired feature will be someone else's
trip wire.

The standards committees do not have unlimited resources (either of time
or manpower).  In addition each of us has/had our own favourites to
champion (though I did adopt a couple of externally written proposals
from UK experts who were unable to attend international meetings)

>2) why not to extend operator overoading to any valid identifier (excluding
>reserved keywords). In my engineering applications I feel a shortage of
>standard operators that can be overloaded. I'd like to define something like
>"operator AND_NOT"(that is often not equivalent to ! && chain), etc. and
>possibly operators that accept more than 2 parameters (it's always possible
>to define rules how to deal with ambiguous constructs in this case). Also
>allow some standard operators to be overloaded with different number of
>parameters. For example, I would like to define string operator %(double d)
>{ return string(d*100)+string("%");} so that I may write double a = 0.1;
>cout<<a%; and see 10%.
> It will also allow C++ compiler to perform some functions of
>compiler-compiler. I believe millions of developers will be grateful for
>these features.

Au contraire, I think most developers would find such as the ultimate
reason for using some other language.  The maintenance overheads would
be unsupportable.

The only operator overloading constraint that I find just a little
excessive is the one that prevents me from providing such things as:

long operator * (char, int);

where I can do better than most built in operators.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7ff66h$39n$1@nnrp1.dejanews.com>,
  dag_henriksson@hotmail.com wrote:
> Someone (Bjarne) has already suggested generalizing operator overloading.
> See
> http://www.research.att.com/~bs/whitespace98.pdf
> for details. ;-)

This paper, written just over a year ago (on April 1, 1998), is truely
brilliant. However, I warn you that it might not say what it seems to
say. Pay particular attention to the last two words on the last page.

Also, see http://www.research.att.com/~bs/whitespace.html for more
information.

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi all,
Can somebody give me 5 good reasons why the following features are not
included in the standard.

1) "property" - it's present in BCB and VC++ and is de facto widely
accepted. I found it extremely useful. Don't see why it couldn't be added to
standard. ( and also "closure").

2) why not to extend operator overoading to any valid identifier (excluding
reserved keywords). In my engineering applications I feel a shortage of
standard operators that can be overloaded. I'd like to define something like
"operator AND_NOT"(that is often not equivalent to ! && chain), etc. and
possibly operators that accept more than 2 parameters (it's always possible
to define rules how to deal with ambiguous constructs in this case). Also
allow some standard operators to be overloaded with different number of
parameters. For example, I would like to define string operator %(double d)
{ return string(d*100)+string("%");} so that I may write double a = 0.1;
cout<<a%; and see 10%.
 It will also allow C++ compiler to perform some functions of
compiler-compiler. I believe millions of developers will be grateful for
these features.

Gene.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]