«

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 conceptualization; i.e. classes
can never have or extend an is-a relationship to a scalar.


Ray Gardener
Daylon Graphics Ltd.
http://www.daylongraphics.com
"Heightfield modeling perfected"

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 conceptualization; i.e. classes
> can never have or extend an is-a relationship to a scalar.
>
>
> Ray Gardener
> Daylon Graphics Ltd.
> http://www.daylongraphics.com
> "Heightfield 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

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 conceptualization; 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
conceptualization"? I couldn't find any reference to that on the
'Net.

V

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 conceptualization; i.e. classes
>> can never have or extend an is-a relationship to a scalar.
>>
>>
>> Ray Gardener
>> Daylon Graphics Ltd.
>> http://www.daylongraphics.com
>> "Heightfield 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:perator int(void)
{
return base;
}

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

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

}

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 conceptualization; i.e. classes
>>can never have or extend an is-a relationship to a scalar.
>>
>>
>>Ray Gardener
>>Daylon Graphics Ltd.
>>http://www.daylongraphics.com
>>"Heightfield 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

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 conceptualization; i.e. classes
>>> can never have or extend an is-a relationship to a scalar.
>>>
>>>
>>> Ray Gardener
>>> Daylon Graphics Ltd.
>>> http://www.daylongraphics.com
>>> "Heightfield 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:perator int(void)
> {
> return base;
> }

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

- Pete

>
> And then, when something tries to mess with your "base" value, which
> ofcourse will be protected, you can interfer:
>
> counter:perator= (int& sauce)
> {
> if //....
>
> }

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 conceptualization; i.e. classes
>>> can never have or extend an is-a relationship to a scalar.
>>>
>>>
>>> Ray Gardener
>>> Daylon Graphics Ltd.
>>> http://www.daylongraphics.com
>>> "Heightfield 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

> Violate the concept? Who said that the concept had to stay
intact?
> Besides, where did you find that "concept of uniform type
> conceptualization"? 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