[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-programming-e
Subject:    Re: [suse-programming-e] Header Files, CommonC++ && All that?
From:       Jerry Feldman <gfeldman () attbi ! com>
Date:       2003-03-28 13:10:35
[Download RAW message or body]

On Fri, 28 Mar 2003 00:46:17 -0500
"Steven T. Hatton" <hattons@globalsymmetry.com> wrote:

> As I suspected, /inline/ has a special meaning within C++.  It has to
> do with how the method/function is dealt with on the activation stack.
>  By default 
> all methods declared within the class body are inline.  
(I think you mean "defined" not "declared". 
A function that is defined within the scope of a class definition is
inline by default. You can also define a function in a .cpp file and
declare it as inline. Inline functions are expanded within the body of
your source code when they are used. This may result in considerable
code bloat. The advantage of inline is that an inline function is a bit
faster than a non-inline function. Also, some C compilers may inline
commong C library functions, such as strlen(). 
Additionally, static class variables must also be defined within the C++
source file, not in the header file. I generally inline my constructors,
destructors, and some of the overloaded operators, but if a function is
more than a couple of lines, I generally do not inline it. 
> > Additionally, it is not
> > imperative that all functions in a C++ program be class members.
> 
> This I understand.  I just believe it is, in general, a bad idea.
Why do you think it is a bad idea. For the most part, I think that one
should define classes properly, but there are always some cases where
you may need or want a function that is not part of a class. This
depends on the circumstances. One of the beauties of C++ is that it does
not enforce object orientation. There are some circumstances where OO
does not fit well. George Orwell once wrote "Break any of these rules
sooner than say anything outright barbarous". This also applies to
computer programming. I have always used the axiom that a program should
be readable and maintainable. I have also written COBOL programs that
were 90% assembler language (in old Burroughs systems). Sometimes the
objective might be in conflict with the readability and maintainability
axiom. One also must remember that C, C++ and Java are different
languages with a common background. When writing code in one language,
one should adapt one's coding style to that language. What is good for
Java may not be good for C++ or vice-versa.  
-- 
--
Gerald Feldman <gfeldman@attbi.com>
Boston Computer Solutions and Consulting
ICQ#156300 PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

-- 
To unsubscribe, email: suse-programming-e-unsubscribe@suse.com
For additional commands, email: suse-programming-e-help@suse.com
Archives can be found at: http://lists/archive/suse-programming-e

[prev in list] [next in list] [prev in thread] [next in thread]