NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/c/20276

Text File | 1993-01-28 | 3.2 KB | 94 lines

Xref: sparky comp.lang.c:20276 comp.lang.c++:19960
Path: sparky!uunet!opl.com!hri.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: discriminated unions (Re: C/C++ Correctness (was: Re: C/C++ Speed))
Message-ID: <[e-mail]>
Date: 26 Jan 93 20:43:05 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Lines: 80
Nntp-Posting-Host: extro.ucc.su.oz.au

In article <[e-mail]> [e-mail] (Eric Smith) writes:
>In article <[e-mail]> [e-mail] (John MAX Skaller) writes:
>>    Later I can write a breadth first search.
>>    I dont have to change anything to write the breadth first search.
>>    Its just a global function taking the tree as an argument.
>
>Ok, now I understand.  You want to be able to add functionality to a class
>without changing the class itself nor deriving a new version of it.

    I'm not sure what you mean by 'add functionality'.

    The public 'member functions' of a class are the axioms. They are
there to map the private data structure of the class to a public interface.
For reasons of efficiency we sometimes have some coupling between
member functions.

    But in general, a function that acts on the public interface
of a class and has no need to know the internal implementation details
should be a global function.

    For example:

    class complex {
        float real, imaginary;
    public:
        float Real () const;
        float Imag () const;
        float Arg () const;
        float Mod () const;
    };

Thats it: now

    complex sin(complex);

Global function==implmentation independent. Making the complex
'sin' a member would be wrong in principle and acceptable only
if a there were a signicant gain in efficiency due to accesssing the private
implementation details.

>Your
>discriminated unions would be helpful toward that goal, but I still don't
>see any overwhelming advantage of that goal.  The only real advantage I can
>see is that you don't have to use a new class name for your new version.
>
>Other than cluttering class name space, are there any disadvantages in
>deriving new classes to add functionality?

    Of course. Unless you adopt a mixin strategy, you cant
use a member function breadth first search on a tree you're
handed which is NOT of the derived type. Thats why you
SHOULD write the searches as global functions, and NOT make
them member functions.

    You want your code to be reusable dont you?

    class complex_with_trig : public complex {
        complex_with_trig sin()const;
    };

    f(complex z)
    {
        ...
        complex_with_trig zz=z;
        complex zzz=zz.sin(); // YUK and inefficient
        ...
    }

    f(complex z)
    {
        ...
        complex zzz=sin(z); // nice
        ...
    }

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------