Who wishes for typecpy in addition to typedef?

Discussion in 'C++' started by Keith H Duggar, Jan 25, 2004.

  1. Often I've felt that the ability to alias an existing type where the
    alias would be treated as a different type thus allowing overloading,
    etc would be very useful.

    typedef : alias an existing type Foo as Bar where Bar is a Foo
    typecpy : alias an existing type Foo as Bar where Bar is not a Foo

    Here is a simple example :

    typecpy std::valarray<double> RowVector ;
    typecpy std::valarray<double> ColVector ;

    This would allow you grab all the existing functionality of valarray
    and at the same time overload, for example, the arithmetic operators
    to act differently on column and row vectors. If you try to gain this
    funtionality by inheritance :

    class RowVector : public std::valarray<double> { ... }
    class RowVector : public std::valarray<double> { ... }

    then you are forced to tediously rewrite or forward all of the
    valarray constructors.

    Actually, in my experience I have run into many cases where typecpy
    would save time, code, and effort. I know at least some others share
    this feeling. For example in a 1999 thread suggesting the removal of
    typedef Dave Harris wrote :

    > Sometimes I want a new type, and sometimes I want a new name for an
    > existing type. Not having a good mechanism for doing the former is a
    > problem, but typedef is still needed for the latter.
    >
    > Ideally we might have 2 keywords, eg:
    > typedef - define a new type.
    > typename - give a new name to an existing type.
    >
    > although for backwards compatibility typedef is unlikely to change now.



    Do any of you think you would benefit from typecpy or think it is a
    good idea? Any not?

    I'm no compiler expert but it seems that this extension would be
    almost trivial to implement. Is that accurate?

    The only sticky point I can think of would be in deciding how typecpy
    would interact with inheritance. For example :

    class Base { ... } ;
    class Derv : public Base { ... } ;

    typecpy Derv Copy ;

    Should Copy be considered a Base?

    It seems to me the easiest solution would be to say that Copy is a
    Base. In other words, Copy is exactly what you would get if you
    exactly copied Derv's declaration and definition and then replaced the
    word Derv with Copy.

    Wouldn't that be a very easy and useful extension to implement?

    Can you think of cases were typecpy would be useful to you?
     
    Keith H Duggar, Jan 25, 2004
    #1
    1. Advertising

  2. "Keith H Duggar" <> wrote in message
    news:...
    > Often I've felt that the ability to alias an existing type where the
    > alias would be treated as a different type thus allowing

    overloading,
    > etc would be very useful.
    >


    The same proposal was made at comp.std.c++ today. Here's my reply:

    ---------------------

    ""Rafal Dabrowa"" <> wrote in message
    news:buldfh$2u2$...
    >
    > Ada has a possibility to derive a new type from an existing one.
    > Derived type behaves like original, but, unlike a type defined by

    typedef,
    > can't be used interchangeably with another derived types (unless
    > explicitly casted). Why C++ does not have such possibility ?
    > Suppose that we define such types like typedef, using "newtype"

    keyword:
    > newtype int MONEY_T;
    > newtype int WEIGHT_T;
    >


    You seem to be advocating "strong typedefs". This has been discussed
    for C++, with the following syntax:

    strong_typedef int money_t;
    strong_typedef int weight_t;

    See "Asepcts of Forwarding" by Lois Goldthwaite
    (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1395.txt).

    Jonathan
     
    Jonathan Turkanis, Jan 25, 2004
    #2
    1. Advertising

  3. Hey that's exactly want I want. Thanks Jonathan. I hope it is added
    and I hope they call it something shorter than strong_typedef. typecpy
    seems perfect.
     
    Keith H Duggar, Jan 27, 2004
    #3
  4. "Keith H Duggar" <> wrote in message
    news:...
    > Hey that's exactly want I want. Thanks Jonathan. I hope it is added
    > and I hope they call it something shorter than strong_typedef.

    typecpy
    > seems perfect.


    No problem. It's hard to tell from that note how well received the
    idea is and what its chances are.

    Jonathan
     
    Jonathan Turkanis, Jan 27, 2004
    #4
  5. Keith H Duggar

    Attila Feher Guest

    Keith H Duggar wrote:
    > Often I've felt that the ability to alias an existing type where the
    > alias would be treated as a different type thus allowing overloading,
    > etc would be very useful.

    [SNIP]
    > Wouldn't that be a very easy and useful extension to implement?


    There have been many discussions about this. The answer is: it might be
    easy to implement, but it has zero legit use.

    > Can you think of cases were typecpy would be useful to you?


    Nope. There were times when I thought it would make sense, but as it turns
    out it makes absolutely no sense. If you want a new type, that new type
    will always be different from the other one - in other ways than its name.

    --
    Attila aka WW
     
    Attila Feher, Jan 28, 2004
    #5
  6. > > Can you think of cases were typecpy would be useful to you?
    >
    > Nope. There were times when I thought it would make sense, but as it turns
    > out it makes absolutely no sense. If you want a new type, that new type
    > will always be different from the other one - in other ways than its name.


    Interesting. It's a kind of mirage feature. You think it would be
    useful but then when you look closer it disappears. You are right that
    it has been discussed a lot I was just looking in the wrong group.
    comp.std.c++ has a lot of material regarding it.
     
    Keith H Duggar, Jan 28, 2004
    #6
  7. Keith H Duggar

    Attila Feher Guest

    Keith H Duggar wrote:
    >>> Can you think of cases were typecpy would be useful to you?

    >>
    >> Nope. There were times when I thought it would make sense, but as
    >> it turns out it makes absolutely no sense. If you want a new type,
    >> that new type will always be different from the other one - in other
    >> ways than its name.

    >
    > Interesting. It's a kind of mirage feature. You think it would be
    > useful but then when you look closer it disappears. You are right that
    > it has been discussed a lot I was just looking in the wrong group.
    > comp.std.c++ has a lot of material regarding it.


    Usually there are very few places where it seems to be useful, and basically
    it is nearly always around "fundamental" types, where I say "fundamental",
    because string belongs here as well. For string, you wish for it, so that
    you do not need to make all the constructors by hand. But then again you
    soon find out, that:

    1.) There are motions to create such inheritance where constructors are
    "inherited"

    2.) You will need more change than just the type name

    3.) It is usually a bad idea to inherit from string, instead of containing
    one. You "get too much" functionality

    4.) Simple name change either creates an unrelated new type (there is not
    way to change it) or a new type, which can be converted to string. In the
    first case: you cannot use it as a string without serious casting business,
    in the latter case you loose type safety.

    The _only_ place where it seems (at first sight) to make sense to me now is
    to create new (standard) size types, on which you can overload. But, then
    again, I can easily imagine that if I start to think about it a bit more, it
    will turn out to be useless as well. IIRC right now, the size_type member
    typedef of all (most?) standard library elements (providing it) "translates"
    to std::size_t. So it is not possible to overload anything. OTOH it may
    not make sense either, since if I use a size value "alone", it is just a
    size. Without seeing the container itself one cannot really do container
    dependent things with it...

    --
    Attila aka WW
     
    Attila Feher, Jan 29, 2004
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Midnight Java Junkie

    Office Development (feature addition)

    Midnight Java Junkie, Jun 20, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    460
    Midnight Java Junkie
    Jun 20, 2004
  2. dandelion

    [OT] Seasonal Best Wishes

    dandelion, Dec 24, 2004, in forum: C Programming
    Replies:
    0
    Views:
    306
    dandelion
    Dec 24, 2004
  3. AMT2K5
    Replies:
    3
    Views:
    367
    Bob Hairgrove
    Dec 10, 2005
  4. oor
    Replies:
    0
    Views:
    1,357
  5. Satish Talim

    Best Wishes for 2008

    Satish Talim, Dec 30, 2007, in forum: Ruby
    Replies:
    0
    Views:
    101
    Satish Talim
    Dec 30, 2007
Loading...

Share This Page