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,42e401e32683b965 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!11g2000yqr.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: A new notion: stronglly-typed-by-user language Date: Sat, 17 Apr 2010 15:02:18 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <57119c7d-eb78-4904-a2de-bf183b03ccf0@r18g2000yqd.googlegroups.com> NNTP-Posting-Host: 85.1.204.101 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1271541738 22683 127.0.0.1 (17 Apr 2010 22:02:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 17 Apr 2010 22:02:18 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 11g2000yqr.googlegroups.com; posting-host=85.1.204.101; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:11019 Date: 2010-04-17T15:02:18-07:00 List-Id: On 17 Kwi, 20:57, "J-P. Rosen" wrote: > Precisely. You showed you can add type safety to the language - which > means that there is not built-in type safety. No. I have shown that the language is capable of supporting user- defined integer types. There is nothing *added* to the language - everything is plain vanilla standard C++. That is, there was nothing missing in there. > Here is what I had in mind. If you have: > void p (short S); > void p (long L); > and you call p (I) where I is an int, it will resolve to the first one > if short and int are the same, and to the second one if long and int are > the same. This is logical No. Not only it is not logical - it will not even compile. First of all, type int is never subject to promotion. "Lower" types can be promoted to int if necessary and this is promotion. Apart from this, integer types can be converted between each other. Promotion has higher rank than conversion in overload resolution and this is basically the only place where the distinction between them is relevant. That is: void foo(char) {} void foo(int) {} short s = 42; foo(s); // this calls foo(int), // because promotion short->int is possible // and has a higher rank // than conversion short->char. Your example above cannot compile, because the actual parameter int cannot be promoted to long (int is never promoted, only "lower" types are) and its conversion to either short or long has equal rank - therefore the call is ambiguous. This has *nothing* to do with representation - these types are all different even if they have the same representation. > the idea that > overloading resolution (and the associated promotion) depends on the > implementation will make any Ada lawyer faint ;-) Overload resolution does *not* depend on implementation in C++, it is precisely defined with no relation to representation. > > There are many bad ideas in C++. I don't see how this one affects > > strong type safety. > > See above I still don't see how this or anything else that was mentioned since the beginning of this thread affects strong type safety. Especially when the presented arguments are incorrect. OK. I'm a C++ programmer and I know how to answer my question. I'm actually surprised that nobody came up with valid explanation of why C+ + sucks for so long, yet many people were ready to make fun of C++ as a language that obviously must suck. This shows that there is a significant bias component in your argumentation and that makes it (the argumentation) much less effective. In other words, you can use it to "preach to the choir", but you cannot use it to reach to an audience that might actually benefit from what you want to say. Just imagine - what would happen if there was a C++ programmer on your tutorial and you presented these arguments? ;-) ;-) ;-) Here is a valid argument that you can use: 1. C++ as a language has a *subset* that supports strong type safety in the sense that it is not possible to modify the value of any type by bypassing the interface of that type. If you stick to that language subset, you are safe. 2. C++ also has some features that allow to undermine the type safety by means of untyped or loosely typed *aliases*. In particular, pointer arithmetic (this includes all kinds of buffer overflows), conversions through void*, reinterpret_casts, unions and dangling pointers all allow to modify values of type T by means that are outside of T's interface and *that* is what makes the whole language unsafe and the sad reality is that these features are too frequently used - most likely because they are too easy to use. You can use point 1. if you want to convince someone that it is possible to build a reliable system in C++. There are people who believe in it and there are such systems. You can use point 2. to convince someone that C++ is not the best choice when support for reliability is required. The argument about untyped aliases is valid and widely acknowledged - even within the C++ community, and if anybody objects you can refer to any well known security vulnerability to make your point. This can create an opportunity to later highlight the advantages of Ada and perhaps recruit some new Ada converts. I hope that this will allow you to better address your audiences. Even if there is a C++ programmer listening. ;-) -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4