From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,690ce1f62160d05a X-Google-Attributes: gid103376,public X-Google-Thread: 1094ba,690ce1f62160d05a X-Google-Attributes: gid1094ba,public X-Google-Thread: 1014db,690ce1f62160d05a X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,690ce1f62160d05a X-Google-Attributes: gid109fba,public From: Gregory Pietsch Subject: Re: How to Design an Application Programmers' Interface (API) Date: 2000/08/13 Message-ID: <3996C42F.2713C90A@flash.net>#1/1 X-Deja-AN: 657806012 Content-Transfer-Encoding: 7bit References: <39921178.819F6DCB@netwood.net> <399386EF.4F2AA3E6@netwood.net> <3996456C.CAD018D5@netwood.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 966182167 38.26.139.235 (Sun, 13 Aug 2000 10:56:07 CDT) Organization: FlashNet Communications, http://www.flash.net MIME-Version: 1.0 NNTP-Posting-Date: Sun, 13 Aug 2000 10:56:07 CDT Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.fortran,comp.lang.ada Date: 2000-08-13T00:00:00+00:00 List-Id: "E. Robert Tisdale" wrote: > > The ANSI C computer programming language > does not support Object Oriented Programming very well. Of course not. It was never an OOP language. > It has an encapsulation mechanism (struct) for creating new types > and a mechanism (typedef) for creating synonyms for existing types > but it doesn't really provide any mechanism > for hiding the data members of a struct except for opaque data types. Yawn... That's because we C programmers don't even WANT any mechanism for hiding the data members. > The definition of an opaque data type > is never exposed to the application program > so the only way to create, manipulate and destroy opaque data types > is by passing pointers to library functions. > This means that memory for all opaque data types > must be allocated from free storage (on the heap) > which can involve significant overhead for small objects. e.g. FILE in . > Another, less effective, method > for hiding the private data members of a struct in ANSI C > is to provide the application program with a dummy type definition > > typedef struct { > int dummy[new_type_size/sizeof(int)]; > } new_type; > > which is the same size as the new type > but conceals the name and location of all private data members. > The advantage of dummy type definitions is that memory for them > may be allocated from automatic storage (on the stack) > with virtually no overhead. In other words, a union of the real type with an array of int (or char) the same size? What fun. > > The problem with opaque data types and dummy type definitions is that > none of the functions that create, manipulate and destroy them > can be implemented as inline functions or C preprocessor macros. > This problem is solved by using library functions > together with opaque data types or dummy type definitions > during program development, debugging and testing > then, just before placing the application into service, > the private type definition is substituted > for the opaque or dummy data type definition, > the inline functions and/or C processor macros are substituted > for the external library functions > and the application program is recompiled. Seems a little complicated. Why don't I just write the program? > The advantage of using the external library functions > during application program development, debugging and testing > is that application programs usually compile faster > if they don't need to process inline functions or C preprocessor macros > and the compiler can diagnose programming errors more precisely. > Application programmers must NOT be obliged > to access private data members directly. Fine. Whenever I write C++ programs, I'll avoid adding get/set methods. > The library must provide functions > which application programmers can use > to create, manipulate and destroy objects as efficiently as possible. Don't have a problem with that. > If the library API fails to specify such functions > and programmers write applications > which access private data members directly, > library developers will never be able to change > the actual data representation, > the meaning of any data member > or even the name of any data member > without breaking existing application programs. > But, if the library API specifies such functions > and library developers make a reasonable attempt > to hide the actual type definition and private data members > so that applications programmers can't access them directly by accident, > then library developers are at liberty to change the data representation, > including the meaning, location, name and number of data members > at any time just by redefining the library functions > that access them directly and redistributing the library. This is getting into OO philosophy more than anything. Later, Gregory Pietsch