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,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!blackbush.cw.net!cw.net!feed.news.tiscali.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Wed, 09 Mar 2005 16:33:11 +0100 From: Georg Bauhaus Organization: future apps GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1110377260.350158.58730@z14g2000cwz.googlegroups.com> In-Reply-To: <1110377260.350158.58730@z14g2000cwz.googlegroups.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <422f16d2$0$1089$9b4e6d93@newsread2.arcor-online.net> NNTP-Posting-Date: 09 Mar 2005 16:31:30 MET NNTP-Posting-Host: d0c820a1.newsread2.arcor-online.net X-Trace: DXC=MT?:[Y9ED_VMYeRE0Pb_HUQ5U85hF6f;TjW\KbG]kaMXliQbn6H@_EY`E5j9;Y9=RSljUVjRQ60?RVmnOeiOY3@^g[50F7T5IOR X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8940 comp.lang.c++:44776 comp.realtime:1131 comp.software-eng:4689 Date: 2005-03-09T16:31:30+01:00 List-Id: Hans Malherbe wrote: > * in Ada, loop variables (a) are constants and (b) do not exist outside > of the loop > > This is safer, but limiting. > In C++ may want to declare the variable outside the loop, > break out early and use the loop variable. Let me guess: You can't > break out early in Ada, right? No, there is all kind of loop control, loop_statement ::= [loop_statement_identifier:] [iteration_scheme] loop sequence_of_statements end loop [loop_identifier]; Inside the loop (sequence_of_statements) you can break out using for example exit [loop_name] [when condition]; (And you can start a new nested block inside a loop with a package in it with a task type in it etc. if that makes sense in a program.) > * case statements (Ada's equivalent of a switch in C++) are required > to handle all possible cases. Thus it is impossible to forget one. > And, of course, there is no "break;" crap in Ada. > > Prevents fall through. Yes, no fall through in "case ... end case", which is why case and switch are not exactly equivalent. There is nice grouping of cases. You can write fall through switches though, when necessary, or desirable, only they won't look like a case distinction. > A few other questions: > > Do you have nested functions like Pascal have? Can you access local > variables? Can you pass pointers to these functions around? Yes. There are restrictions on pointers to locally allocated objects used in an outer scope. The restricted items include local functions, e.g. there are no full upward closures. > Can you pass non-type parameters (like the number 3.14) to templates? Yes, formal template parameters include floating point types and values. > Can templates recurse? No. (Though you can mix recursive subprograms, nesting, and template instantiation.) I think that it is *this* fact ("recursive templates"), the "programmability of a C++ compiler via templates", that allows a C++ programmer to do many things that otherwise aren't available in the language. For example, the Can_Copy, Can_This, Can_That idiom is built into Ada, Eiffel, etc. via constraint genericity, and so doesn't require a "template computing compiler" for constraining. OTOH, this is a limitation, even though there is a richt set of "parameter things" in Ada, including types, interface types, values, subprograms, and packages (templates parameterized by other templates). > Can you program "const correct"? Eg. if you declare a member function > as const the compiler will help you not mutate the object or call any > functions that do. The const-mechanics are slightly different. In order to preclude modifications of the object, use parameter modes, see below. The analog of the this pointer is passed to a primitive operation, i.e. a member function. Ada 2005 adds dotted notation in addition to passing a this-like value. Now, if a subprogram's parameter modes disallow modifying the "this parameter", you can't modify the object's state in the subprogram body (without trickery that is). > Also, if you pass a parameter as a const reference, > you will not be able to mutate the object the parameter references. The passing modes are, in, in out, and out. They are logical and indeed separate from direct or indirect access to the values at the processor instruction level. The compiler usually chooses what it thinks is best when the language leaves this open. Georg