dev-cpp-users — Dev-C++ users discussion list

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

[Rodolfo d'E. <rod...@la...>]

Lets remember, we can program in Fortran using any language, including c =
and c++

Rodolfo d'Ettorre

RE: RES: [Dev-C++] generated .exe is too big

[Per W. <pw...@ia...>]

_Bool does not increase size of final executable.

_Complex and (possibly) long long increases the size of the executable -
but only for executables that needs them, and then it can hardly count. An
opengl executable is larger than a hello world, but that isn't a
deficiency of opengl but just that the opengl application solves a harder
problem.

Without the _Complex data type, you have to implement - or link through an
existing library - your own complex math. And by doing that, the
application has to be larger or the application wouldn't work.

If you don't use _Complex but decides on defining an own data type and
then implement complex_add(), complex_mul(), ... the application will not
make any references to the _Complex helper functions and won't link in
them. No extra size of the executable added, at least for non-debug where
the compiler haven't thrown in a lot of data declarations seen in header
files etc just for good measure.

The only complaint I think I have about _Complex - too long time ago I
looked at the specification - was that some of the NaN/Infinity handling
didn't felt mathematically sound. But that is a completely different
issue.

/Per W

On Thu, 24 Apr 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Thursday, April 24, 2003 5:26 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: RES: [Dev-C++] generated .exe is too big
> >
> >
> > The changes for C99 should not make a real difference in quality of
> > mapping against hardware.
> >
> > [...]
> >
> > _Complex operators needs either multiple assembler
> > instructions or calls
> > to helper functions, to handle all combinations of NaN and
> > infinities. No
> > difference from support of float and double on a processor without fp
> > support. Linker wouldn't add these helper functions unless needed.
>
>
> Yes but there are processors with fp support. However there isn't any with
> complex support.
>
>
>
> > It isn't possible to add _Bool and _Complex as just typedef,
> > since it's a
> > question of giving the language the correct operators too. In C++ with
> > operator overloading we can add a _Complex type on our own,
> > but in C it
> > has to be made as a hard-coded data type.
>
>
>
> I mean they could avoid polluting the namespace. And what about size_t? In
> C99 it can be some type other than the provided standard built in ones, and
> yet is provided through header file only.
>
> In any case, these things do increase the size of the final executable.
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
> Anti-racism movement: http://www.positive-youthfoundation.org
> Iraq Peace Pledge: http://www.peacepledge.org
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

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

[Ioannis V. <iv...@at...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Thursday, April 24, 2003 5:53 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: RES: [Dev-C++] Re: C and C++
> 
> 
> Just about any feature of any language somehow have both pros 
> and cons.
> The net result is that whatever languag that are used, the 
> programmer has
> to spend more or less time on every single line, deciding if 
> the line is
> more good or evil regarding the target goals of the application.
> 
> Net result: Use whatever language that is available and fits the bill.
> Just make sure that you know why you use the language, and 
> that you know
> what the used features of the language actually do.
> 
> It is impossible to create a language that is always at least 
> as good as
> any other language. To get such a language, you have to add 
> new features
> to the language, and a lot of these new features MUST result 
> in some form
> of penalties making other languages more fit for use according to that
> specific criteria. An example: A jack of all trades language has to be
> large. But then it MUST be harder to learn than a specialized language
> dedicated to solving some specific subset problems.


I agree. One must choose the right tool for the right job.



Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net


Anti-racism movement: http://www.positive-youthfoundation.org
Iraq Peace Pledge: http://www.peacepledge.org

RE: RES: [Dev-C++] generated .exe is too big

[Ioannis V. <iv...@at...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Thursday, April 24, 2003 5:26 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: RES: [Dev-C++] generated .exe is too big
> 
> 
> The changes for C99 should not make a real difference in quality of
> mapping against hardware.
> 
> [...]
> 
> _Complex operators needs either multiple assembler 
> instructions or calls
> to helper functions, to handle all combinations of NaN and 
> infinities. No
> difference from support of float and double on a processor without fp
> support. Linker wouldn't add these helper functions unless needed.


Yes but there are processors with fp support. However there isn't any with
complex support.



> It isn't possible to add _Bool and _Complex as just typedef, 
> since it's a
> question of giving the language the correct operators too. In C++ with
> operator overloading we can add a _Complex type on our own, 
> but in C it
> has to be made as a hard-coded data type.



I mean they could avoid polluting the namespace. And what about size_t? In
C99 it can be some type other than the provided standard built in ones, and
yet is provided through header file only.

In any case, these things do increase the size of the final executable.


Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net


Anti-racism movement: http://www.positive-youthfoundation.org
Iraq Peace Pledge: http://www.peacepledge.org

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

[Per W. <pw...@ia...>]

Yes, it's possible to write C++ programs using only the C subset.

However, in my book a program not using templates, objects, operator
overloading etc is a C program even if the source files happens to have
the cpp extension and we use the C++ compiler for generating the object
files.

It isn't just a question of if the object files gets the C or C++ binding,
it's a question of what design concepts that are used.

For just about every improvement to a language, there is also often a
cost, and it's up to the individual programmers to decide the individual
merits of the pros and the cons.

_Bool in a c rogram is of course an improvement, since strict type
checking makes for error free applications while allowing better
optimization by he compiler. BUT, the cost in this case is portability.

Objects does improve code quality and greatly increases code reusability,
BUT at the cost of resultin in fragmentation of CPU cache.

Templates greatly reduced the number of lines to write in a program,
thereby reducing possibilities of adding new bugs BUT at the cost of
increasing the application size through binary code duplication.

Operator overloading allows superb integration of new data types, such as
vector addition etc in beautiful code BUT at the cost of not always being
intuitive, i.e. when you look at the code it might require a lot of mental
work to figure out all type conversions taken place in a single 'a += 2 *
b + c' line, just to figure out which operator overloads that actually
gets called.

...

Just about any feature of any language somehow have both pros and cons.
The net result is that whatever languag that are used, the programmer has
to spend more or less time on every single line, deciding if the line is
more good or evil regarding the target goals of the application.

Net result: Use whatever language that is available and fits the bill.
Just make sure that you know why you use the language, and that you know
what the used features of the language actually do.

It is impossible to create a language that is always at least as good as
any other language. To get such a language, you have to add new features
to the language, and a lot of these new features MUST result in some form
of penalties making other languages more fit for use according to that
specific criteria. An example: A jack of all trades language has to be
large. But then it MUST be harder to learn than a specialized language
dedicated to solving some specific subset problems.

/Per W

On Thu, 24 Apr 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of Per Westermark
> > Sent: Thursday, April 24, 2003 1:58 AM
> > To: Daniel K. O.
> > Cc: dev...@li...
> > Subject: Re: RES: [Dev-C++] Re: C and C++
> >
> >
> > One problem with bigger code is that just about all
> > applications larger
> > than hello world is getting bigger than the processor cache. That,
> > together with multiple concurrently running programs, make us
> > loose a lot
> > of the total processoer capacity in costly cache misses.
> >
> > That is one situation where it is a bit easier to optimize in
> > a C program
> > - a non-OO program makes it easier to place all costly functions close
> > together in a single file, letting them better fit in the cache.
>
>
> Or use the procedural paradigm of C++ (the C subset). A language having
> almost C90 as a subset can't be any slower than C!
>
>
> For direct hardware optimisation the C subset is to be used, that's the
> rational thing to do. Please people do not confuse that C++ is only OO!
> Anyone uses the combination of paradigms that fit the purpose.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
> Anti-racism movement: http://www.positive-youthfoundation.org
> Iraq Peace Pledge: http://www.peacepledge.org
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: RES: [Dev-C++] generated .exe is too big

[Per W. <pw...@ia...>]

The changes for C99 should not make a real difference in quality of
mapping against hardware.

_Bool should map perfectly - no difference than the bool type in C++.

long long might be either multiple assembler instructions or calls to
helper functions, but no difference from the normal long type on a 8 or
16-bit processor. The linker need not add these extra helper functions
unless they are called in the compiler-emitted object files.

_Complex operators needs either multiple assembler instructions or calls
to helper functions, to handle all combinations of NaN and infinities. No
difference from support of float and double on a processor without fp
support. Linker wouldn't add these helper functions unless needed.

It isn't possible to add _Bool and _Complex as just typedef, since it's a
question of giving the language the correct operators too. In C++ with
operator overloading we can add a _Complex type on our own, but in C it
has to be made as a hard-coded data type.

/Per W

On Thu, 24 Apr 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of Louis Godio
> > Sent: Wednesday, April 23, 2003 6:17 PM
> > To: David Matthews; dev...@li...
> > Subject: Re: RES: [Dev-C++] generated .exe is too big
> >
> >
> > David and List,
> > It seems unbelievable that the same code compiled with gcc 2.95
> > generates a 5kb exe file, compared to 35kb when compiled under
> > gcc3.2. A 100% increase would be bad enough; but this is a 700%
> >  increase ??
> >
> > Can other DevC++ users comment on this ?
>
> My assumption is the new C99 built in types and library facilities are what
> caused that increase (the default is C99 now!). That implies that you get
> the built in _Bool with values 0 or 1, built in _Complex type, long long,
> etc. C no more maps directly in the machine (C++ still does). That is CPUs
> do not have complex types.
>
> All these types with the _ can be used without _ in the normal way e.g.
> complex y; by including the corresponding header file (e.g. #include
> <complex.h>).
>
>
> What I personally would have liked is that they could have made available
> these "exotic" types (because they are not made using general purpose
> facilities), as typedefs through the header files only.
>
>
> Well, as Dennis Ritchie told, there will not be any new K&R.
>
>
> C++98 provides specialised facilities made using general purpose facilities.
>
>
> Some references:
>
> http://www.itworld.com/AppDev/710/lw-02-stroustrup/page_1.html
>
> http://www.itworld.com/Comp/3380/lw-12-ritchie/page_1.html
>
>
> Check what they say about C99.
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
> Anti-racism movement: http://www.positive-youthfoundation.org
> Iraq Peace Pledge: http://www.peacepledge.org
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

[Dev-C++] RE: c or c++. that is the question

[jp <rar...@xt...>]

C is an assembler macro language

C++ is C with classes (inheritance, protected members and a vtable), =
templates (structured preprocessing), exceptions and stricter type =
checking.  C++ features generally map to underlying concepts available =
in C, such as exceptions mapping to setjmp/longjmp plus some =
book-keeping of the stack. Early C++ actually compiled to C (CFront).

C++ is not a first class OO language, and as such can't claim the =
benefits of, say LISP or Python. I won't mention the J word, because it =
is afflicted with brittle base class syndrome, and intrusive library =
syndrome... And I won't mention VB either...

Being so close to assembler, C is (comparatively) easy to retarget, and =
it is (comparatively) easy for a programmer to understand the impact his =
code is having 'on the metal'. Thus C, but probably not C++, can be used =
to program the uC in your washing machine.

C and C++ are systems programming languages, and it seems to me they are =
overkill for 99% of the tasks they are applied to. I direct the person =
who doubts this to the Mozilla project, which uses XML for much of the =
detail, and to the Python VTK bindings, which make scientific =
visualization an efficient and interactive pastime.

This said, I use C++ most of the time. I often wrap C libraries and =
other APIs with classes, and I like the way C/C++ enables integration of =
third party code and binaries without the overburden of something like =
ActiveX or custom bindings. I write a lot of tools and subsystems, and I =
think C and C++ are good for this. Also, I'm blundering thru a machine =
vision project at the moment, and although there are various tools that =
do some of what I need (Lush, VXL), I'm preferring to go minimalist, and =
use C/C++, including source for functions as I need them.

One of my favourite languages is PostScript. I doubt there are many =
implementations of it that aren't written in C/C++.=20

Like any trade, half the battle is knowing the tool for the job...

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

[Ioannis V. <iv...@at...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Per Westermark
> Sent: Thursday, April 24, 2003 1:58 AM
> To: Daniel K. O.
> Cc: dev...@li...
> Subject: Re: RES: [Dev-C++] Re: C and C++
> 
> 
> One problem with bigger code is that just about all 
> applications larger
> than hello world is getting bigger than the processor cache. That,
> together with multiple concurrently running programs, make us 
> loose a lot
> of the total processoer capacity in costly cache misses.
> 
> That is one situation where it is a bit easier to optimize in 
> a C program
> - a non-OO program makes it easier to place all costly functions close
> together in a single file, letting them better fit in the cache.


Or use the procedural paradigm of C++ (the C subset). A language having
almost C90 as a subset can't be any slower than C!


For direct hardware optimisation the C subset is to be used, that's the
rational thing to do. Please people do not confuse that C++ is only OO!
Anyone uses the combination of paradigms that fit the purpose.




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net


Anti-racism movement: http://www.positive-youthfoundation.org
Iraq Peace Pledge: http://www.peacepledge.org

RE: RES: [Dev-C++] generated .exe is too big

[Ioannis V. <iv...@at...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Louis Godio
> Sent: Wednesday, April 23, 2003 6:17 PM
> To: David Matthews; dev...@li...
> Subject: Re: RES: [Dev-C++] generated .exe is too big
>=20
>=20
> David and List,
> It seems unbelievable that the same code compiled with gcc 2.95=20
> generates a 5kb exe file, compared to 35kb when compiled under
> gcc3.2. A 100% increase would be bad enough; but this is a 700%
>  increase ??
>=20
> Can other DevC++ users comment on this ?

My assumption is the new C99 built in types and library facilities are =
what
caused that increase (the default is C99 now!). That implies that you =
get
the built in _Bool with values 0 or 1, built in _Complex type, long =
long,
etc. C no more maps directly in the machine (C++ still does). That is =
CPUs
do not have complex types.

All these types with the _ can be used without _ in the normal way e.g.
complex y; by including the corresponding header file (e.g. #include
<complex.h>).


What I personally would have liked is that they could have made =
available
these "exotic" types (because they are not made using general purpose
facilities), as typedefs through the header files only.


Well, as Dennis Ritchie told, there will not be any new K&R.


C++98 provides specialised facilities made using general purpose =
facilities.


Some references:

http://www.itworld.com/AppDev/710/lw-02-stroustrup/page_1.html

http://www.itworld.com/Comp/3380/lw-12-ritchie/page_1.html


Check what they say about C99.



Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net


Anti-racism movement: http://www.positive-youthfoundation.org
Iraq Peace Pledge: http://www.peacepledge.org

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

[Per W. <pw...@ia...>]

One problem with bigger code is that just about all applications larger
than hello world is getting bigger than the processor cache. That,
together with multiple concurrently running programs, make us loose a lot
of the total processoer capacity in costly cache misses.

That is one situation where it is a bit easier to optimize in a C program
- a non-OO program makes it easier to place all costly functions close
together in a single file, letting them better fit in the cache.

If a cache line - the modularity of the CPU cache - is 32 byte, a single
char variable at an unlucky location will result in a cache waste of 31/32
or 97% When overriding a base class, you can't control where any new
member variables are placed in the object.

But then again - for 97% of all applications, it doesn't matter how
efficient the processor is used. They solves so small problems that it is
enough if they just get any processor time at all.

/Per W

On Wed, 23 Apr 2003, Daniel K. O. wrote:

>
>
>
> 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
>  >  >
>  >  >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RES: RES: [Dev-C++] generated .exe is too big

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

 >  With Dev-C++ 4.01 it is 4608 bytes; with Dev-C++ 4.9.8.0 it is 22619
 >  bytes. Compiler options are the same in both cases (any
 >  optimization and
 >  debugging information are switched off).
 >  I tried it with a more complicated console application too: 10240 bytes
 >  vs. 35973 bytes :(
 >  I tried the -Os option too, but it only reduced 1 KB.



What about some benchmarks between the different versions of MinGW? Which
one is faster? Did anyone did it already?




Daniel K. O.

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
 >  >
 >  >

[Dev-C++] mysqlapi

[sergio f. <ser...@ci...>]

Friends:

I am Sergio, I am new c programmer and I am trying to use Devc++. My =
first trouble is when I try to make a Mysql Connection. I don't know how =
to add mysql libraries.
Can someone help me?
Thanks a lot.

Sergio.

Re: RES: [Dev-C++] generated .exe is too big

[Per W. <pw...@ia...>]

See partial answer that I wrongfully managed to send to Samuel Keding - I
missed that he had changed thread name...

/Per W

On Wed, 23 Apr 2003, Louis Godio wrote:

> David and List,
> It seems unbelievable that the same code compiled with gcc 2.95
> generates a 5kb exe file, compared to 35kb when compiled under
> gcc3.2. A 100% increase would be bad enough; but this is a 700%
>  increase ??
>
> Can other DevC++ users comment on this ?
>
> --- David Matthews <dem...@uw...> wrote:
> > That would be the upgrade to gcc3.2, not Dev-C++'s settings.  There've
> > been
> > a lot of questions like this.  You can switch back to gcc2.95 manually
> > if
> > you want to, just uninstall Dev-c++, download the gcc2.95 package from
> > mingw, download standalone Dev-C++ and set it up yourself.  I personally
> > prefer gcc3.2 though.
> >
> > At 12:06 PM 22/04/2003 -0400, David Matthews wrote:
> > >>  >  I have the problem that the generated exe is too big with the
> > version
> > >>  >  4.9.8.0. The same code compiled with Dev-C++ 4.01 is 5 KB, but
> > with
> > >>  >  4.9.8.0 about 35 KB. Debug information is switched off, so I
> > don't know
> > >>  >  what the problem is.
> > >>
> > >> Dev-C++ does not compile anything; if 35 KB is a big problem to you,
> > you
> > >> should ask on MinGW's mailing list (probably somewhere at
> > www.mingw.org).
> > >
> > >Hi!
> > >
> > >I forgot to write that I have had this problem since I upgraded
> > Dev-C++,
> > >so in my opinion it's a problem with the default settings, not with the
> > >compiler. I thought of the debugging info, but it's switched off, so I
> > >don't know what else to change. Is there anyone who had the same
> > problem?
> > >
> > >	Thanks,
> > >
> > >		Laszlo
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf
> > >_______________________________________________
> > >Dev-cpp-users mailing list
> > >Dev...@li...
> > >TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: RES: [Dev-C++] generated .exe is too big

[Szathmary L. <sz...@de...>]

> David and List,
> It seems unbelievable that the same code compiled with gcc 2.95 
> generates a 5kb exe file, compared to 35kb when compiled under
> gcc3.2. A 100% increase would be bad enough; but this is a 700%
>  increase ??
> 
> Can other DevC++ users comment on this ?

Hi,

Last time I wrote the sizes by heart, but now I tried it again:

The example code is:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
  printf("Hello World!\n");
  system("PAUSE");	
  return 0;
}

With Dev-C++ 4.01 it is 4608 bytes; with Dev-C++ 4.9.8.0 it is 22619
bytes. Compiler options are the same in both cases (any optimization and 
debugging information are switched off).
I tried it with a more complicated console application too: 10240 bytes
vs. 35973 bytes :(
I tried the -Os option too, but it only reduced 1 KB.

	Thanks,

		Laszlo

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

[Per W. <pw...@ia...>]

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
>
>
> ____________________________________________________________
> Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
> http://login.mail.lycos.com/r/referral?aid=27005
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: RES: [Dev-C++] generated .exe is too big

[michel.weinachter <mic...@fr...>]

hello,

Did you try the -Os  option ? (O for optimisation, s for small)
The default option (-O0 ) includes a lot of debuging information.

bye

RE: [Dev-C++] c or c++. that is the question

[Ioannis V. <iv...@at...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Khalid El-Kary
> Sent: Wednesday, April 23, 2003 5:26 PM
> To: Dev...@li...
> Subject: RE: [Dev-C++] c or c++. that is the question
> 
> 
> Hi fellows,
> In my point of view, I believe that C is simpler, lower-level.
> simplicity always has some merits, like the mentioned file size issue.
> 
> C++ on the other hand is better structered, geared towards better 
> integration in work and gains higher code-reusability...and the other 
> advantages of OO languages :-)


C++ is not just OO. Supports 4 paradigms including the C's one (and that
with better type checking).


> 
> I don't believe in the way of saying "lang_name is the best" (where 
> lang_name is your prefered language)--every language suites a 
> purpose, and 
> every purpose has a best language for it.
> 
> I believe, C is very good for work where performance makes 
> much difference, 
> performance also means memory usage which is affected by the 
> executable file 
> size. one of the good proofs that C applications are geared towards 
> performance is, the writing of the Apache HTTP server, PHP, 
> Python, MySQL in 
> C, note that all these applications are designed for plain 
> performance, for 
> the high web traffic.



Check my own benchmarks: http://www23.brinkster.com/noicys/cppfaq.htm




> C++, is better in companies work, where you don't have hackers and 
> volunteers, where you have dead lines :-) because it makes 
> the development 
> and maintenance proccess easier. and modularized ...


C++ is excellent for hacking. It leaves no room for a lower level language
except assembly. At the same time provides great abstraction with higher
level facilities.



> 
> personally I always prefer C, since I like the old-style 
> simple things, and 
> since I didn't find a bad behaviour or a draw back in its 
> coding style, I 
> won't change until I'm obliged by a boss ...


It's a religious issue but I consider C++ better since


string s;

cin>>s;


is simpler and safer than char *.


C is OK but especially after C99 I consider it dead (Ioannis takes cover).




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net


Anti-racism movement: http://www.positive-youthfoundation.org
Iraq Peace Pledge: http://www.peacepledge.org

RE: [Dev-C++] c or c++. that is the question

[Louis G. <lg...@ya...>]

Reid,
Does "stripped" mean no debug info ?

--- Reid Thompson <Rei...@at...> wrote:
> initial file sizes compiled on cygwin gcc/g++.
> these compiled on RH 7.2 gcc/g++ - not as large a difference, but a
> difference.
> Not sure how that would equate out if the program was 10K lines, or 100K
> lines, etc
> gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2)
> 
> -rwxr-xr-x    1 rthompso staff       13738 Apr 23 07:29 tst*
> -rwxr-xr-x    1 rthompso staff       14765 Apr 23 07:29 tstCpp*
> stripped
> -rwxr-xr-x    1 rthompso staff        4088 Apr 23 07:31 tstCpp*
> -rwxr-xr-x    1 rthompso staff        3272 Apr 23 07:31 tst*
> 
> #include <stdio.h>
> 
> int main(void)
> {
>     printf("hello world\n");
>     return 0;
> }
> 
> 
> #include <iostream>
> using namespace std;
> 
> class Hello
> {
>     public:
>     void print(void)
>     {
>         cout << "hello world" << endl;
>     }
> };
> int main(void)
> {
>       Hello* p = new Hello;
>       p -> print();
>       delete p;
>       return 0;
> }
> 
> reid
> 
> 
> > -----Original Message-----
> > From: Khalid El-Kary [mailto:kha...@ho...] 
> > Sent: Wednesday, April 23, 2003 12:19 AM
> > To: Dev...@li...
> > Subject: RE: [Dev-C++] c or c++. that is the question
> > 
> > 
> > One question:
> > 
> > is there a extern "C++" like there's extern "C" ?
> > 
> > if there's isn't, C code will be more useable, for both C++ 
> > and C programms. 
> > (?)
> > 
> > 
> > Khalid
> > >Ioannis wearing his bullet-proof vest:
> > >
> > >
> > >Keep in mind that the prevalent X-Window library now is a 
> > C++ one. Also
> > >most
> > >new GNU/Linux programs are being written in C++ these days...
> > >
> > >
> > >File sizes for the hello world program should not be different.
> > >
> > >
> > >
> > >
> > >Ioannis Vranos
> > >
> > >* Programming pages: http://www.noicys.freeurl.com
> > >* Alternative URL 1: http://run.to/noicys
> > >* Alternative URL 2: http://www.noicys.cjb.net
> > >
> > >
> > >Anti-racism movement: http://www.positive-youthfoundation.org
> > >Iraq Peace Pledge: http://www.peacepledge.org
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: dev...@li...
> > >[mailto:dev...@li...] On Behalf Of Reid 
> > >Thompson
> > >Sent: Wednesday, April 23, 2003 6:03 AM
> > >To: dev...@li...
> > >Subject: RE: [Dev-C++] c or c++. that is the question
> > >
> > >
> > >many reasons..., here's the first that comes to my mind....
> > >size:
> > >-rwxrwxrwx    1 Reid.Tho Domain U    19223 Apr 22 22:22 tstC.exe*
> > >-rwxrwxrwx    1 Reid.Tho Domain U   448506 Apr 22 22:29 tstCPP.exe*
> > >stripped:
> > >-rwxrwxrwx    1 Reid.Tho Domain U    10240 Apr 22 22:32 tstC.exe*
> > >-rwxrwxrwx    1 Reid.Tho Domain U   219136 Apr 22 22:32 tstCPP.exe*
> > >
> > >
> > >and ease of use is subjective :)
> > >
> > >#include <stdio.h>
> > >
> > >int main(void)
> > >{
> > >     printf("hello world");
> > >     return 0;
> > >}
> > >---------------------------
> > >#include <iostream>
> > >using namespace std;
> > >
> > >int main(void)
> > >{
> > >     cout << "hello world";
> > >     return 0;
> > >}
> > >
> > >or, since everything 'should' be a class/object:
> > >
> > >#include <iostream>
> > >using namespace std;
> > >
> > >class Hello
> > >{
> > >     public:
> > >     void print(void)
> > >     {
> > >         cout << "hello world" << endl;
> > >     }
> > >};
> > >int main(void)
> > >{
> > >       Hello* p = new Hello;
> > >       p -> print();
> > >       delete p;
> > >       return 0;
> > >}
> > >-rwxrwxrwx    1 Reid.Tho Domain U   449115 Apr 22 22:51 tstCPP.exe*
> > >stripped
> > >-rwxrwxrwx    1 Reid.Tho Domain U   219648 Apr 22 22:55 tstCPP.exe*
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >reid
> > >-----Original Message-----
> > >From: jose isaias cabrera [mailto:ji...@fr...]
> > >Sent: Tuesday, April 22, 2003 10:17 PM
> > >To: dev...@li...
> > >Subject: [Dev-C++] c or c++. that is the question
> > >
> > >
> > >
> > >Greetings!
> > >
> > >Here is a question for all: why would anyone use c when c++ 
> > is so much 
> > >easier?
> > >
> > >josé
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf 
> > _______________________________________________
> > >Dev-cpp-users mailing list
> > >Dev...@li...
> > >TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > 
> > 
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
> > http://join.msn.com/?page=features/featuredemail
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

Re: RES: [Dev-C++] generated .exe is too big

[Louis G. <lg...@ya...>]

David and List,
It seems unbelievable that the same code compiled with gcc 2.95 
generates a 5kb exe file, compared to 35kb when compiled under
gcc3.2. A 100% increase would be bad enough; but this is a 700%
 increase ??

Can other DevC++ users comment on this ?
 
--- David Matthews <dem...@uw...> wrote:
> That would be the upgrade to gcc3.2, not Dev-C++'s settings.  There've
> been
> a lot of questions like this.  You can switch back to gcc2.95 manually
> if
> you want to, just uninstall Dev-c++, download the gcc2.95 package from
> mingw, download standalone Dev-C++ and set it up yourself.  I personally
> prefer gcc3.2 though.
> 
> At 12:06 PM 22/04/2003 -0400, David Matthews wrote:
> >>  >  I have the problem that the generated exe is too big with the
> version
> >>  >  4.9.8.0. The same code compiled with Dev-C++ 4.01 is 5 KB, but
> with
> >>  >  4.9.8.0 about 35 KB. Debug information is switched off, so I
> don't know
> >>  >  what the problem is.
> >>
> >> Dev-C++ does not compile anything; if 35 KB is a big problem to you,
> you
> >> should ask on MinGW's mailing list (probably somewhere at
> www.mingw.org).
> >
> >Hi!
> >
> >I forgot to write that I have had this problem since I upgraded
> Dev-C++,
> >so in my opinion it's a problem with the default settings, not with the
> >compiler. I thought of the debugging info, but it's switched off, so I
> >don't know what else to change. Is there anyone who had the same
> problem?
> >
> >	Thanks,
> >
> >		Laszlo
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Dev-cpp-users mailing list
> >Dev...@li...
> >TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
> >
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

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

[Samuel K. <ib...@ly...>]

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


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

RE: [Dev-C++] Localization ?

[Khalid El-K. <kha...@ho...>]

thanx fellow :-)

> > -----Original Message-----
> > From: Ioannis Vranos [mailto:iv...@at...]
> > Sent: Wednesday, April 23, 2003 7:52 AM
> > To: 'Dev...@li...'
> > Subject: RE: [Dev-C++] Localization ?
> >
> >
> > From the creator himself:
> >
> >
> > http://www.research.att.com/~bs/3rd_loc0.html
> >
> >
> > There he has a link to a pdf for locales.
>
>
>That pdf is part of the book but he has made it available online too.
>
>
>
>
>Ioannis Vranos
>
>* Programming pages: http://www.noicys.freeurl.com
>* Alternative URL 1: http://run.to/noicys
>* Alternative URL 2: http://www.noicys.cjb.net
>
>
>Anti-racism movement: http://www.positive-youthfoundation.org
>Iraq Peace Pledge: http://www.peacepledge.org
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

RE: [Dev-C++] c or c++. that is the question

[Khalid El-K. <kha...@ho...>]

Hi fellows,
In my point of view, I believe that C is simpler, lower-level.
simplicity always has some merits, like the mentioned file size issue.

C++ on the other hand is better structered, geared towards better 
integration in work and gains higher code-reusability...and the other 
advantages of OO languages :-)

I don't believe in the way of saying "lang_name is the best" (where 
lang_name is your prefered language)--every language suites a purpose, and 
every purpose has a best language for it.

I believe, C is very good for work where performance makes much difference, 
performance also means memory usage which is affected by the executable file 
size. one of the good proofs that C applications are geared towards 
performance is, the writing of the Apache HTTP server, PHP, Python, MySQL in 
C, note that all these applications are designed for plain performance, for 
the high web traffic.

C++, is better in companies work, where you don't have hackers and 
volunteers, where you have dead lines :-) because it makes the development 
and maintenance proccess easier. and modularized ...

personally I always prefer C, since I like the old-style simple things, and 
since I didn't find a bad behaviour or a draw back in its coding style, I 
won't change until I'm obliged by a boss ...

HTH

Regards,
Khalid Al-Kary

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: [Dev-C++] RE: c++ help

[jose i. c. <ji...@fr...>]

> >I want to know what I need to do now. I know how to output text, take
> >input, use strings, and perform logical operations. What is the next
> >step? If I want to become better at the C++ language, what is the best
> >way to go on in terms of writing a program?

if you have programmed before, in any language, take the easiest of the
programs and code it for c++ and make it work.  Then, gradually move up to
your hardest and longest program and also make it work and you'll be ready
to take a task.

Otherwise, I have a few projects that you could start helping me with... ;-)

josé

Re: [Dev-C++] c or c++. that is the question

[jose i. c. <ji...@fr...>]

Well, perhaps I was prematured in posing the question.  I can see your =
point.  My first project was to parse through up to ten text files of =
2megs each and create a report and it was very complicated using text =
handling functions to split a line, to search through a really long line =
of text, etc... Then finding out that c++ has string functions, I was =
like, "dude, nice!" :')

jos=E9

  ----- Original Message -----=20
  From: Norman Gonsalves=20
  To: dev...@li...=20
  Sent: Wednesday, April 23, 2003 1:57 AM
  Subject: Re: [Dev-C++] c or c++. that is the question


  On Tue, 22 Apr 2003 22:16:34 -0400 "jose isaias cabrera" =
<ji...@fr...> writes:

  >Here is a question for all: why would anyone use c when c++ is so =
much easier?

  Two obvious reasons are executable code size and compiler capability.

  Code written in C usually generates smaller executables than code =
written in C++. Because of this you are more likely to use C only for =
embedded applications.

  If you are using a C only compiler (and there still several around) =
then the use of C only is a given. Many older C/C++ compilers will have =
a lot of trouble with modern ANSI C++, but will probably work fine with =
C code. Also, there are several interpreters and script languages based =
on C, but very few based on (the more complex) C++.

  Is C++ really easier to use than C? The answer is a matter of opinion =
..... many will disagree!

  Norm