Re: Why use C++?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 16.08.11 10:47, Dmitry A. Kazakov wrote:

> A premature optimization does not guaranty you anything about performance,
> in fact the opposite. Unless your claim is that a deliberate use of a wrong
> representation (e.g. shorter than required) might result in a better
> performance, due to malfunction.

Isn't a program closer to optimal in some formal sense when

- the type stays as declared, i.e., without representation affecting
  values ("percent" = {0..100}) and operations (+, -, ...) in  the
  abstract, but

- eventually, one set of machine operations reflects the program's
  purpose better that another (customers preferring the faster/smoother/
  more stable/uninterrupted performance)?

IOW, both programs will perform the same system functions, but
one does more "efficiently" than the other.  And sells better.
Choosing a different type may change the program's meaning.
Is changing only the representation of types, not the types,
necessarily premature optimization?

Compilers, or their writers, try to achieve good representations.
Why shouldn't programmers at least try the same when the program
has matured and can be polished without hurting any of the system
functions?  As long as this attempt doesn't evolve into general hubris?
And most importantly, as long as the type of values does not change,
as it must standard-wise, for example, in C++ when s/int/long/, say?

In this sense, I think any kind of representation specification is
somewhat like a pragma that says optimize space or optimize time.
Anything wrong with pragmatic hints?

Imagine redefining "int" to be something like

__internal.hpp:

class int <lo, hi, predicate=id>
{
    __int<lo, hi> value;
public:
    ...
};

where __int<...> chooses a compile time checked representation.