From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b92b95c9b5585075 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!news-out.readnews.com!transit4.readnews.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 16 Aug 2011 12:23:48 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? References: <1e292299-2cbe-4443-86f3-b19b8af50fff@c29g2000yqd.googlegroups.com> <1fd0cc9b-859d-428e-b68a-11e34de84225@gz10g2000vbb.googlegroups.com> <9ag33sFmuaU1@mid.individual.net> <1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net> <150vz10ihvb5a.1lysmewa1muz4$.dlg@40tude.net> <1q4c610mmuxn7$.1k6s78wa0r8fj.dlg@40tude.net> <1vn800hbyx8k4$.1lsveclj56197$.dlg@40tude.net> <1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4e4a4534$0$7629$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 16 Aug 2011 12:23:49 CEST NNTP-Posting-Host: 90345605.newsspool1.arcor-online.net X-Trace: DXC=4<7BN5[ROiB[6=1B@oB@@@ic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgB8V6?4Fa=5gKnc\616M64>JLh>_cHTX3jMg>kcX\UK[LD X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.c++:92804 comp.lang.ada:21616 Date: 2011-08-16T12:23:49+02:00 List-Id: On 16.08.11 10:47, Dmitry A. Kazakov wrote: > A premature optimization does not guaranty you anything about performance, > in fact the opposite. Unless your claim is that a deliberate use of a wrong > representation (e.g. shorter than required) might result in a better > performance, due to malfunction. Isn't a program closer to optimal in some formal sense when - the type stays as declared, i.e., without representation affecting values ("percent" = {0..100}) and operations (+, -, ...) in the abstract, but - eventually, one set of machine operations reflects the program's purpose better that another (customers preferring the faster/smoother/ more stable/uninterrupted performance)? IOW, both programs will perform the same system functions, but one does more "efficiently" than the other. And sells better. Choosing a different type may change the program's meaning. Is changing only the representation of types, not the types, necessarily premature optimization? Compilers, or their writers, try to achieve good representations. Why shouldn't programmers at least try the same when the program has matured and can be polished without hurting any of the system functions? As long as this attempt doesn't evolve into general hubris? And most importantly, as long as the type of values does not change, as it must standard-wise, for example, in C++ when s/int/long/, say? In this sense, I think any kind of representation specification is somewhat like a pragma that says optimize space or optimize time. Anything wrong with pragmatic hints? Imagine redefining "int" to be something like __internal.hpp: class int { __int value; public: ... }; where __int<...> chooses a compile time checked representation.