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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Running a preprocessor from GPS? Date: Thu, 30 Jul 2015 09:01:06 +0300 Organization: Tidorum Ltd Message-ID: References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com> <91f88d79-197c-419f-84a8-908e05967a2c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 3neUgyJ/WoB2MLdNLCPokAaZFFdZPoG5j4Sww+y5YOBlyI2ADB Cancel-Lock: sha1:aJhWwP7YREQ+Lgth84Ogw3qhroM= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <91f88d79-197c-419f-84a8-908e05967a2c@googlegroups.com> Xref: news.eternal-september.org comp.lang.ada:27165 Date: 2015-07-30T09:01:06+03:00 List-Id: On 15-07-30 03:10 , EGarrulo wrote: > On Thursday, July 30, 2015 at 1:51:50 AM UTC+2, Jeffrey R. Carter wrote: >> On 07/29/2015 03:32 PM, EGarrulo wrote: >>> >>> If Ada offered runtime typing by means of a type `Any`, then `Printf` >>> could be trivially written as: >>> >>> type Printf_Arguments is array (Positive range <>) of Any; >>> >>> procedure Printf (Format : String; Arguments : Printf_Arguments); >> >> Luckily nothing this horrible will ever make it into Ada. I agree with Jeffrey. > Who knows? But since the realm of Ada is limited to embedded > development, It isn't. > it makes sense that flexible formatted output will never > be a priority. Having used both, in my opinion the Ada way is more flexible than the C printf approach. As long as all variables are explicitly typed "int" or "char" or "long", etc, as in classical C programming style, printf works tolerably; as soon as one introduces some kind of type abstraction such as "typedef ... apple_count_t", constructing the right format-string becomes awful, especially if portability is a goal. Look at the standard header in C99; to make a portable format string for apple_count_t, one would also to define a specific format macro (perhaps named PRI_APPLE_COUNT) and perhaps another macro for scanf, and use this macro within the format string. Not to mention the maintenance problems in keeping the format string and the argument list consistent, even if C compilers nowadays have special compile-time checks for this. The only improvement in the basic Ada output facilities that I wish for is a standardisation of the GNAT 'Img attribute and extension of this attribute to cover record and array types. That would occasionally be useful for quick-and-dirty outputs like tracing outputs. On the other hand, tracing functions originally meant to be temporary often become permanent and then a quick-and-dirty formatting may not be enough. I usually write specific Image functions for my types anyway. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .