<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
<br><ul><li>opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations)</li></ul><br>Just to be clear, that power is not easily created, and would not be do-able in the constrained form I suggested, where it is always, e.g. T +(T,T)<br><br><div class="ecxgmail_quote"> > <b>not</b> proper in terms of semantics (<font style="" class="ecxApple-style-span" face="'courier new', monospace">operator<<</font> and <font style="" class="ecxApple-style-span" face="'courier new', monospace">operator>></font> being obvious cases)<br><br>This would not be allowed in my constrained proposal.<br><br>> but also <font style="" class="ecxApple-style-span" face="'courier new', monospace">operator+</font> for concatenation<br><br>This is very reasonable.<br><br> > utterly painful uses for <font style="" class="ecxApple-style-span" face="'courier new', monospace">operator,</font>)<br><br><br>I'm surprised that is overloadable, but indeed it appears it is. I don't think I have *ever* seen anyone overload it, and I have seen a lot.<br>
<br><br> > the inability to define <b>new</b> operators (which leads to the first problem of idiots redefining the semantics of operators)<br><br><br>Stroupstroup rejected this as too complex. (See the Design&Evolution book).<br>I don't see people pine for this often and I suspect he did the right thing.<br>It creates a layering problem I believe in the typical structure.<br>The lexical analysis would have to get information from higher layers.<br><br><br> > unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible<br><br><br>This is already the case. As I said. So let's say that every single function call is shown. It is hard to know which functions have which cost.<br>There are also hidden function calls e.g. for "try" and every pointer derereference (right?)<br><br><br>Please consider floating point. Historically floating point was "soft float". Sometimes these days it still us. Yet we still have operators for floating point.<br>Why? Because it is just so convenient and idiomatic. Why stop there?<br><br><br>A primary design point of C++ is to give user defined types all the powers of built in types.<br>No longer does it require a compiler change to introduce a type with the "power" of int. And so on.<br><br><br>
> painful interaction with templates that makes a perfect storm of eye-damaging syntax</div><br>Huh? Specifically?<br><br>The one vague reason I don't fully understand is: C doesn't have it.<br>Does C represent a good example of a sort of minimalism? Maybe.<br>It isn't clear to me the value of C. It has been *very* widely abandoned in favor of C++.<br><br> - Jay<br> </body>
</html>