Inheriting scalars

[Ray Gardener]

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids? This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.
Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfiel d modeling perfected"

[Petec]

Ray Gardener wrote:

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids? This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.
Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfiel d modeling perfected"

While that's not allowed, you can do something like:

class counter
{
int base;
public:
counter(int b): base(b) {}
operator int() {return base;}

/* operators such as + * - / ++ -- etc */
};

I believe that has the same effect as the one you want...

- Pete

[JKop]

Petec posted:

Ray Gardener wrote:

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids? This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.
Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfiel d modeling perfected"

While that's not allowed, you can do something like:

class counter
{
int base;
public:
counter(int b): base(b) {}
operator int() {return base;}

/* operators such as + * - / ++ -- etc */
};

I believe that has the same effect as the one you want...

- Pete

I would suggest piggybacking on the predefined intrinsic int operators, by
defining an int cast operator:

counter::operat or int(void)
{
return base;
}

And then, when something tries to mess with your "base" value, which
ofcourse will be protected, you can interfer:

counter::operat or= (int& sauce)
{
if //....

}

[Victor Bazarov]

Ray Gardener wrote:

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids?
There probably was. Intrinsic types are not classes. The main
reasons for separating the intrinsic types are the backwards
compatibility and optimisation.
This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.

Violate the concept? Who said that the concept had to stay intact?
Besides, where did you find that "concept of uniform type
conceptualizati on"? I couldn't find any reference to that on the
'Net.

V

[Victor Bazarov]

Petec wrote:

Ray Gardener wrote:

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids? This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.
Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfiel d modeling perfected"

While that's not allowed, you can do something like:

class counter
{
int base;
public:
counter(int b): base(b) {}
operator int() {return base;}

Better be
operator int () const { return base; }

/* operators such as + * - / ++ -- etc */
};

I believe that has the same effect as the one you want...

For ++ and -- you would also have to add

operator int&() { return base; }

Then it _might_ have the sought effect.

V

[Petec]

JKop wrote:

Petec posted:

Ray Gardener wrote:

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids? This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.
Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfiel d modeling perfected"
While that's not allowed, you can do something like:

class counter
{
int base;
public:
counter(int b): base(b) {}
operator int() {return base;}

/* operators such as + * - / ++ -- etc */
};

I believe that has the same effect as the one you want...

- Pete

I would suggest piggybacking on the predefined intrinsic int
operators, by defining an int cast operator:

counter::operat or int(void)
{
return base;
}

That's exactly what I had, do you mean
counter::operat or int&() {...}
?

- Pete

And then, when something tries to mess with your "base" value, which
ofcourse will be protected, you can interfer:

counter::operat or= (int& sauce)
{
if //....

}

[Petec]

Victor Bazarov wrote:

Petec wrote:

Ray Gardener wrote:

C++ doesn't allow:

class counter : public int {};
Was there any special reason why base class ids can only be
struct/class ids? This limitation appears to violate the
concept of uniform type conceptualizati on; i.e. classes
can never have or extend an is-a relationship to a scalar.
Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfiel d modeling perfected"

While that's not allowed, you can do something like:

class counter
{
int base;
public:
counter(int b): base(b) {}
operator int() {return base;}

Better be
operator int () const { return base; }

Yes, thanks for pointing that out. I have a tendency to forget about const.
;)

/* operators such as + * - / ++ -- etc */
};

I believe that has the same effect as the one you want...

For ++ and -- you would also have to add

operator int&() { return base; }

Then it _might_ have the sought effect.

Why would it not work with manually defining all overloadable operators for
it instead?

- Pete

V

[Ray Gardener]

> Violate the concept? Who said that the concept had to stay
intact?

Besides, where did you find that "concept of uniform type
conceptualizati on"? I couldn't find any reference to that on the 'Net.

Well, it just strikes me as odd that a scalar is a type, and a
class is a type, but they can't be uniformly treated in the same
manner. Class counter can never _be_ an integer; it can only
_contain_ an integer member.

On the other hand, the scalars are machine-level types. In the
future we might see a stdlib header file that has:

// types.h -- standard types

class int { ... };
class float { ... };
class double { ... };
....

/*
The traditional scalar typenames are now actually classes and
can be treated like any other class. The actual machine-level
numeric scalars are private and compiler/platform dependant.
If the compiler sees that it can optimize a "scalar" down
to its machine equivalent, it will do so automatically.
*/

Then again, that wouldn't work for C code... it'd have to assume
that C has been obsoleted.

Ray