Menu
▾
▴
dev-cpp-users
|
From: Samuel K. <ib...@ly...> - 2003-04-23 14:51:27
|
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 |
|
From: Per W. <pw...@ia...> - 2003-04-23 22:05:53
|
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 > |
|
From: Daniel K. O. <dan...@ya...> - 2003-04-23 22:38:14
|
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 > > > > |
|
From: Per W. <pw...@ia...> - 2003-04-23 22:59:08
|
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 > |
|
From: Ioannis V. <iv...@at...> - 2003-04-24 01:20:17
|
> -----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 |
|
From: Per W. <pw...@ia...> - 2003-04-24 02:54:33
|
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 > |
|
From: Ioannis V. <iv...@at...> - 2003-04-24 03:01:47
|
> -----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 |
