|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 11 July 2002 18H:53, Noah Silva wrote:
> On Wed, 2002-07-10 at 20:14, Jason wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > It doesn't seem like 2 is a plethora of functions to me. Actually, I find
> > that one of the many benefits of OO is fewer function names that
> > accomplish the same thing, sometimes due to overloading,
>
> "Function overloading" can be done without OOP at all.
Assuming that your non-OOP language is procedural, it would be quite difficult
if your procedural language allowed function declarations without declaring
argument types.
It just so happens that I was generally referring to C++ compared to the
original straight C that was common arround the time that C++ started to get
developed.
In the "C subset" that is part of C++, due to stricter type checking for
function prototypes implemented in C++, you could make use of "Function
overloading".
But, early 80s straight C did not necessarily consider the argument types to a
function as part of the function declaration. Particularly, the older style
of function declaration syntax.
In the newer "function prototype" style, a C compiler could allow mutliple
function prototypes with the same name and different argument lists, but this
would have been much harder to implement when the argument types were not
part of the function declaration.
Fuller use of "function overloading" is also much better supported in OOP and
C++ due to better localization, including limiting scope within classes and
namespaces.
Some of the stricter type checking has found its way back into newer C
specifications, but certainly can't be said of all straight C implementations
back in the early 80s. I haven't followed the newer non-C++ C languge
specifications (C99, etc.) as much, but that's not where C++ originated from.
Plus, I was actually referring more to "member functions" than specifcally
just "Function overloading". In either case, IMHO you are more likely to see
more different function names in straight C (sprintf, snprintf, vsprintf,
...) and more implementations of the same function name in C++ (sometimes due
to overloading - as I mentioned above - and sometimes due to inheritance - as
I mentioned below).
Then there's also template functions... But, that's a whole other discussion.
>
> > sometimes due to inheritance. So,
> > in the example given, rather than printf, vprintf, etc. you replace that
> > with cout, or more generally streams. Now, you have one concept to learn
> > that applies in many different instances. That way, you don't have to
> > memorize a lot of function names that all do similar things.
> >
> >
<snip>
>
> And with too much inheritance and too many virtual functions you have a
> slow-ass program ;)
This is not as true in C++ as in other OO languages. Probably more
*compromises* were made to maintain effieciency in C++, than strictly
maintaining backward compatibility with C. For example, many consider the
lack of garbage collection to be a performance tradeoff.
Having said that, too much of just about anything will result in a slow-a$%
program...
- -Jason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj0vLK4ACgkQ3CryLfCgqRmxrwCfR+U05HSgRI80aj76nrn9ijr0
uPcAn1+Axw+PnDMog/1xFoKDrGZL7Iag
=79Yr
-----END PGP SIGNATURE-----
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|