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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,174ec7dc941a1068 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!b79g2000hse.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Factory Pattern Date: Fri, 27 Jul 2007 05:47:34 -0700 Organization: http://groups.google.com Message-ID: <1185540454.137500.28610@b79g2000hse.googlegroups.com> References: <1185387571.367570.163160@r34g2000hsd.googlegroups.com> <1185432247.046242.24300@o61g2000hsh.googlegroups.com> NNTP-Posting-Host: 137.138.37.241 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1185540454 31005 127.0.0.1 (27 Jul 2007 12:47:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 27 Jul 2007 12:47:34 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070724 Red Hat/1.5.0.12-0.3.slc3 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: b79g2000hse.googlegroups.com; posting-host=137.138.37.241; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1225 Date: 2007-07-27T05:47:34-07:00 List-Id: On 27 Lip, 12:16, "Jeffrey R. Carter" wrote: > > No. C and C++ have enumerations. > > Which are just names for integer values, last time I looked. No. There are implicit conversions to int, but enums are separate types. > The type of > a function parameter would be int. No. Each enum is a separate type: #include enum E1 {a, b, c}; enum E2 {x, y, z}; void foo(E1 e) { std::cout << ": foo(E1)\n"; } void foo(E2 e) { std::cout << ": foo(E2)\n"; } void foo(int e) { std::cout << ": foo(int)\n"; } int main() { std::cout << static_cast(a); foo(a); std::cout << static_cast(x); foo(x); int i = 0; std::cout << i; foo(i); } This program prints: 0: foo(E1) 0: foo(E2) 0: foo(int) which means that even though a and x have the same value when converted to int, they are distinct from int and between each other and can be properly picked by separately overloaded functions. > And even if that's not the case, > experienced users are accustomed to doing it this way from the days > before it had them. I consider myself to be an experienced user of C++ and I don't seem to remember it working the way you describe. I'm not a dinosaur though, so I might have missed a thing or two as well... > And even newer users are accustomed to seeing it > done this way in the code they've been exposed to. >>From what you write it appears that you have been looking at C++ quite a while ago - in which case I wonder where you get the knowledge of what newer users are exposed to. > And even if that's > not the case, C/++, emphasizing ease of writing over ease of reading, > induces a mindset in the user of "why bother typing this enumeration > definition and using it when I can just say int?" I agree with this. C++ allows the programmer to be explicit about many things, but does not require it. Many programmers, especially those that have been exposed to poorly written C (this is unfortunately unavoidable) or some scripting languages of the Perl league are tempted to reduce the dictionary of their designs and end up with numbers everywhere. In most cases not even named. > All of these are > symptoms of "C/++ thinking". These are symptoms of hacking. Note that we are discussing it not in the context of C++, but in the context of some Ada program that was shown few posts earlier - this shows that hacking is possible in every language and since there are about 2500 of them, there is no reason to distinguish any single one of them as the supposed originator. C++ is not even old enough to be the source of such practices. It just allows them. Like Ada (which is actually older and allowed such bad practices earlier ;-) ). -- Maciej Sobczak http://www.msobczak.com/