RES: [Dev-C++] Re: C and C++

[Daniel K. O. <dan...@ya...>]

I think that a few KB shouldn't be a problem nowadays. If you want a small
binary, you can UPX it, and pay the price of uncompressing the code
everytime you run it. I personally don't mind if the .EXE is bigger, if it
can run faster than a smaller one.



Daniel K. O.




 >  -----Mensagem original-----
 >  De: dev...@li...
 >  [mailto:dev...@li...]Em nome de Per
 >  Westermark
 >  Enviada em: quarta-feira, 23 de abril de 2003 19:04
 >  Para: Samuel Keding
 >  Cc: dev...@li...
 >  Assunto: Re: [Dev-C++] Re: C and C++
 >
 >
 >  We had a long discussion about memory layout and problem porting Fortran
 >  routines efficiently to C++ some moths ago :-)
 >
 >  Well, language comparisons will always pop up in the list more or less
 >  regularly.
 >
 >  One thing about size of binaries.
 >
 >  For a small binary, even a little extra results in a large proportional
 >  difference.
 >
 >  Some few reasons why C++ applications gets larger:
 >  - Mangled names results in larger debug information.
 >  - More complex data structures in the header files results in
 >  larger debug
 >  info.
 >  - Most OS have C-like API, so a lot of low-level C++ classes must in the
 >  end call C function, while the C app sometimes could call the C function
 >  directly.
 >  - C++ compiled with RTTI adds a lot of extra book-keeping in the binary.
 >  - Support for some combinations of multiple-inherritance
 >  results in a lot
 >  of extra code to type-cast between super- and sub-classes.
 >  - Exception support, to correctly find all auto-declared objects to
 >  destruct on the stack.
 >  - Template code that results in code expansion, where the
 >  application gets
 >  several versions of similar code.
 >
 >  Yes, there are a number of reasons why a C++ application might
 >  be smaller
 >  too, such as good use of virtual methods to better reuse code
 >  in abstract
 >  base classes etc...
 >
 >  However, the most common reason for larger C++ binaries is that libc++
 >  adds in a lot of extra goodies that quickly bloats small programs, but
 >  makes large applications grow slower because of code reuse.
 >
 >  /Per W
 >
 >  On Wed, 23 Apr 2003, Samuel Keding wrote:
 >
 >  > Hey,
 >  >
 >  > A language doesn't equal religion. For those of you who can
 >  only read C or C++
 >  >
 >  > bool isEqual = (language == religion)
 >  >
 >  > cout or printf isEqual
 >  >
 >  > On the console appears 0.
 >  >
 >  > It doesn't really matter a lot. C can be more effiecent at
 >  times, and ease is a matter of opinion. Some problems are
 >  easier to understand in the object oriented sense. In that
 >  case, C++ will probably be easier. In any case a langauge is a
 >  tool. If your welding you might want a welding torch. However,
 >  you probably do not want to use a welding torch when drying the
 >  clothes. You probably want to use a dryer for that. C, C++,
 >  Java, Fortran, use them where it proves useful. Oh, one other
 >  thing, Fortran is evil. Do not use it.
 >  >
 >  > :D
 >  >
 >  >