From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.lang.c++
Subject: Inheriting from inbuilt types (was: Re: Two things...)
Date: 17 Nov 92 19:30:52 GMT
Organization: University of Birmingham

In article <Bxu1Gp.M9o@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
> In article <1992Nov16.202036.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>>...
>>There is a presedent for using the token `class' in this way:
                                                      ^^^^^^^^ (to mean `type')
>>  `template<class T>' "class" meaning "T is a symbol of type class"
>>...
>...
> Why does the syntax for a template require the class keyword when templates
> are instantiable to the predefined types of C++ (int, double, etc.,.)?
As I said class here is used to mean type, there are such things as
template arguments with types other than `class'.

template <class T,int sz> class buffer { T v[sz]; /*...*/ };
     (from "The C++ Prog Lang Ed.2" p279)
> 
> I suspect the reason is to disambiguate expressions and class/type names
> as parameters to templates.  However, it is a wonderful start towards 
> perhaps making the predefined types of C++ behave as classes.  It would
> be nice to be able to inherit from int or float, for instance.  Anyone
> who would want to do something like this today needs to make a class
> with an int or float member.  Most compilers that I've run into still
> generate code which accesses the single member like a struct even though
> it is at offset zero in the struct.
> 
> What would we do for syntax?  How about this:
>  
> class Integer : public int
> {
>     public:
>         operator int () { return *this; }
> };
Actually you wouldn't need to specify this as conversion to a base class
is automatic. 
> 
> *this would be the access for the int portion of an Integer.  Note that
> if there were additional members in class Integer, an int cast would have
> the effect of "object-slicing" *this to only the int portion.
> I'm not sure if such lvalue casting is now allowed. 
Yes it implicitly calls the aforementioned compiler supplied conversion
operator. I often have member functions that `return *this' and actually
involve a type conversion. Unfortunately the example you cite would
be an infinite recursion! 
> 
> All of this is off
> the top of my head, but I think that making the predefined types into 
> classes would certainly help the orthogonality of the language.
>  
> The syntax of templates certainly suggests that predefined types are
> sort of like classes, doesn't it?
Yes I've often sat in the bath contenplating if I would like to see
inheritance from inbuilt types. Certianly it would be nice but I think
I have a way of getting the same effect without the need for changing the
language. The fact that conversions between inbuilt types are handled
differently from conversions between user defined types will always
mean that you could never inherit all the properties of an inbuilt type.

I  propose a standard library header file <intypes.h>

// intypes.h

template <class T> class InType {
  T value;
public:
  operator T() {return value;}
  InType(T v) : value(t) {}
};

template <class T> class Numeric : public InType<T> {

  T& operator+=(const T& that) {value+=that.value; return *this;}
  T operator+(T that) {that.value+=value; return that;}
   // and so on for all the other operators valid on float
};
template <class T> class Integral<T> : public Numeric <T> {
public:
  // all the operators valid for int but not float
};
template <class T> class Pointer : Intype <T*> {
public:
  //all the operators valid for pointers
}

template <class T,int size> class Array {
  T value[size];
public:
  operator Pointer<T> () { return value; }
  operator T* { return value; }
   // and so on a long way
};

template <class T> class Enum<T> { /*...*/ }

OK so the actual class names may need further consideration. (I'd never
actually written this idea down before today).

You can now effectively inherit from int by inheriting from
Integral<int> or from long by inheriting from Integral<long>.
-- 
    \\   ( )    No Bullshit!     |  Email: B.A.McCauley@bham.ac.uk   
 .  _\\__[oo        from         |  Voice: +44 21 471 3789 (home)
.__/  \\ /\@    /~)  /~[   /\/[  |    Fax: +44 21 625 2175 (work)
.  l___\\      /~~) /~~[  /   [  |  Snail: 197 Harborne Lane,
 # ll  l\\    ~~~~ ~   ~ ~    ~  |         Birmingham, B29 6SS, UK
###LL  LL\\   (Brian McCauley)   |   ICBM: 52.5N 1.9W
Newsgroups: comp.lang.c++