Inheriting scalars

R

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 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"
 
P

Petec

Ray said:
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
 
V

Victor Bazarov

Ray said:
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
 
J

JKop

Petec posted:
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::eek: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::eek:perator= (int& sauce)
{
if //....

}
 
V

Victor Bazarov

Petec said:
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
 
P

Petec

JKop said:
Petec posted:



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

counter::eek:perator int(void)
{
return base;
}

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

- Pete
 
P

Petec

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

Yes, thanks for pointing that out. I have a tendency to forget about const.
;)
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
 
R

Ray Gardener

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top