From 4170983140455284902 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,522c04b057796323 X-Google-Attributes: gidf78e5,public From: David R Tribble Subject: Re: main()??? Date: 1997/04/15 Message-ID: <2.2.32.19970415145344.002d4898@central.beasys.com>#1/1 X-Deja-AN: 235053780 X-Original-Date: Tue, 15 Apr 1997 09:53:44 -0500 X-Sender: drt@central.beasys.com Organization: - X-Auth: PGPMoose V1.1 PGP comp.std.c++ Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com I wrote: >> A basic, but arguable, tenet of object-oriented >> programming is that *all* functions and variables are members of classes. >> Other languages, like Java and Eiffel, enforce this. bonnardv@pratique.fr (Valentin Bonnard) responded: > Why ? I write OO program with lots of non-members functions; in > particular, operator<< has to be non-member; what's special with > members functions ? Why are they better than a non-member ? > > Also in the STL design algo aren't (and shouldn't be) members of a > class. A class represent an object: an interface over a > representation. > > Lots of functions just use classes, they don't implement one. Sounds like those functions should be put into classes, then. It appears that you will have a hard time coding in other O-O languages when the need arises. Avoiding classes is anathema to O-O principles, regardless of how nifty templates are. > Perhaps you use classes as namespaces because your compiler > doesn't support them ? Not exactly. What happens when your operator<<() conflicts with a third party's operator<<()? Or when your List class conflicts with someone else's List class? Oh, but I forgot, your single compiler supports namespaces while the eight or nine compilers we use don't. A namespace, by any other name, is just a wrapper class. > IMO the view that everything is a class is just ugly and can > lead to fat classes that know everything. We've never had that problem. Our classes don't get bigger, we just have more classes. Like you said before, each class should embody a single type of object; it has only the necessary functions/operators/algorithms needed for that object. A class should do a few things very well. And some classes can embody a set of algorithms (functions) with no object data at all. You dislike fat classes. What about excess global data and functions? They can be especially annoying because, lacking classes, it's not always obvious how they are grouped together or how they interact. And they tend to be spread out in the source code and third-party libraries, so they can be difficult to track down. We rarely find the need for global data, because practically every function we have operates on object-specific data, even if the object is a static singleton POD. Even ::main() operates on object-specific data, that being the data (object) encompassing the execution of the program (which is usually little more than the command line arguments). Why not write the program that way then, and put it in a class? --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]