Re: C++

[George <jirka 5z com>]

> As for bloat of other features, such as the standard library, the
> results are similar, C++ is very efficient.  For example compiling a
> simple program with a C compiler and a C++ compiler, dynamically linked
> resulted in 0 byte overhead for HP aCC/ansic, and 108 bytes with
> gcc/g++.  For statically linked the files were the same size with
> gcc/g++.  As you bring in more features you will have to pay for them,
> but this is not much different than using additional libraries for C,
> and far superior than hand coding these features yourself.

C++ is efficent for runtime a lot of times ... where it sucks is usually
the compile time ...

the place where the bloat comes into runtime is when people use C++
features to abstract the code too much ... and in most instances this
introduces HUGE performace hits and a lot of times size hits ...

I personally HATE debugging template using code ... just like I hate
debugging code using heavy #defines ...

> Features such as exceptions and RTTI have been mentioned as extra
> bloat.  Exceptions allow an error handling model that can be more
> flexible and safer than anything C has to offer.  As for RTTI, when this
> kind of feature is needed the language implementation is much cleaner
> than any additional code you would have to write yourself.  Most
> features won't increase the size of you code unless you use them, and a
> modest cost for a new feature is not bloat.

exceptions are rarely used well, plus since it's harder to use then say
returning status from a function .... most people don't catch them ...
it's easier to

if(!function())
	...

then

try {
	function();
} catch(...) {
	...
}

plus a lot of times it's much easier to figure out how things are
propagated .... and since catch statements are as they are you sometimes
have to work around to make them work the way you need ...

plus rearely do I want an error cleanly pass through more then a few
levels of functions before doing something about it ...

plsu since msot people seem to use catch(...) which just catches any
exception instead of only the error from the previous function ...

most of the time I need to propagate an error is when creating some object
and then I just return a result of a function and .... the NULL is
propagated ... magic ...

> Some of the bloat seems to come from early implementations of features
> in compilers.  Most of the bloat is the design of the application or
> library itself.  If you ever see an inheritance tree ten deep, beware.
> If you see every method declared virtual, there is a cost.  Other
> sources of bloat I have seen are from poorly designed operator
> overloading, poor handling of temporary objects, and of misuse of an
> otherwise solid library.  For the CORBA stub example above you should
> probably look at improving the generated stubs rather than blaming the
> language for the bloat.  A quote from 'The C++ Programming Language'
> covers this, "Don't believe in magic; understand what your libraries do,
> how they do it, and at what cost they do it".   This should apply to all
> languages, not just C++.

one of the things I don't like about C++ is that it does too much "magic"

> C++ == Object Oriented
> 
> C++ is a general purpose language.  There seems to be an idea that if
> you want to do object oriented programming use C++, otherwise use C.
> This just isn't the case.  C++ supports procedural programming, modular
> programming, data abstraction, object oriented, and generic programming
> (taken from ch 2 of the C++ Programming Language).  Take your choice.
> C, on the other hand only supports procedural and modular well.  The
> others either can't be implemented or require the programmer to code
> around the problem with hacks and enforce these though policy, rather
> than though language features.  On top of this C++ adds stronger typing,
> exceptions, name spaces and many more features.

saying these features are not easily done in C isn't fair .... most
programs will not need these features in such a generalized case ...  in
C you implement them in any way you want, which is usually a way that
exactly fits what you are doing ... a lot of these are implementation
features, and therefore better done in the program not in the language
...

plus C++ also adds a whole bunch of "features" that make the syntax
look ambiguous or support bad programming practices .... to name some,
references and anywhere declarations.

plus I don't think C++ needs all the extra syntax for all this ... look
at ObjectiveC ... it does more then C++ with less syntax ...

> Even if you are not a fan of object oriented programming give C++ a
> try.  For example the Standard Template Library, as part of C++, is NOT
> object oriented, it follows generic programming.  Understanding the
> theory behind the STL is well worthwhile, especially for someone doing
> designs.  To implement the STL in C would be next to impossible.

unfortunately I gate STL a try .... and let me tell you once you get a
bug in a larger project using STL .... it's a bitch to track it down ...

you need containers ... so why not use say glib which has nice containers
for standard types ... I have much less trouble passing around (void *)
then templates ... but then again C++ doesn't like (void *) (it thinks
it's evil and one must go wild with casts)

> Safety
> 
> C++, and its standard libraries, allow for much cleaner handling of
> dynamic types.  Each user defined type can make use of dynamic memory
> and hide the implementation from the user.  Through such features as
> destructors in user defined types the language will enforce rules set by
> the designer, instead of relying on the user to call cleanup functions.
> For example a string in C++ is NOT char*, it is a defined type.  The C++
> string is dynamic, will not overflow, and is much safer than its C
> counterpart.  When the string goes out of scope it will clean up its
> memory, the user need not do anything.  C++ also allows for elegant
> solutions to such things as smart pointers (reference counting pointer
> wrappers).

btw ... C doesn't have a string .... for example on how to do objects as
data types in a nice manner look at gmp or glib

plus most C++ programs use char* for strings still ... I find char* more
flexible, faster and more memory efficent for most uses ... and as long
as there are good string functions available you can do whatever ...
and dynamic strings are possible to ... look at GString in glib ...

reference counting pointers are also not hard in C ... (about as easy as
in C++) ... it takes about 2-3 short functions and an internal structure
with a void * and a refcount integer ... but it's usual that you implement
reference counts not on pointers but on the object itself ... such as in
gtk

> Raising the programming level
> 
> There was mention that the right solution for doing faster GUI
> development is to 'raise the programming level'.  It was noted that
> Tcl/Tk, or Perl binding would be appropriate.  I feel that bindings to
> scripting languages are important for "glue" applications, very small
> applications, and for proto-typing.  For larger scale programming we
> still need to "raise the programming level", however to me this means
> simplifying the API, or providing abstractions.  One method of doing
> this that maps nicely to GUI development is through Object Frameworks.
> Objects allow state information to be held so that the developers of the
> framework can worry about many of the specifics and allow the
> application developer to concentrate on "higher level" design issues.
> Frameworks often present an overhead that may not be appropriate for all
> applications, so that a "nuts and bolts" API must still be available
> (although this too could be object oriented).  The current trend of
> concurrently developing gtk+ (nuts and bolts), gtk-- (slightly higher
> level with objects), wxGTK (full framework), and scripting bindings may
> cover all of the bases.  Visual design (GUBI) may even fill in more.

by far the simplest(fastest) toolkit to use is Tk ... especially in
tcl ... it isn't object oriented ... (well it is just as about any toolkit
is)

C++ uses inheritance mostly to create new gui components ... which I
usually find most irritating .... just to create a dialog with some
insides you have to create a new class? .. I was once forced to do
windows programming in borland's object framework and I was not happy
... (for all I know it might have been easier then straight windows
rpgramming as I have never done that) ... but it was definately not
as easy as gtk ... even motif seemed far simpler to use then that ...

the way it mostly is

gtk+ (nuts and bolts), gnome (full app framework)

> The language in general.
> 
> In general C++ is a strong language with many new features.  Before you
> dismiss it you might want to check it out.

unfortunately I did ... I used to be a C++ programmer ... not any more
... now I'm back to C and loving it ...

George

-- 
------------------------------------------------------------------------------
George Lebl <jirka@5z.com> http://www.5z.com/jirka/
------------------------------------------------------------------------------
  The following implements RSA in perl and is illegal to export from the US:

          #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
          $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
          lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)