From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Received: by 2002:ac8:4050:: with SMTP id j16mr15689638qtl.44.1593439917226; Mon, 29 Jun 2020 07:11:57 -0700 (PDT) X-Received: by 2002:a54:4585:: with SMTP id z5mr12476215oib.110.1593439917007; Mon, 29 Jun 2020 07:11:57 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 29 Jun 2020 07:11:56 -0700 (PDT) In-Reply-To: <5ef9712d$0$1221$e4fe514c@news.kpn.nl> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <5ef9712d$0$1221$e4fe514c@news.kpn.nl> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <49b45a8c-e820-46d1-b04b-2e0b76653fd7o@googlegroups.com> Subject: Re: Hardware independent programming From: Shark8 Injection-Date: Mon, 29 Jun 2020 14:11:57 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59248 List-Id: On Sunday, June 28, 2020 at 10:42:22 PM UTC-6, ldries46 wrote: > Hardware can in some cases have limits you have to consider when writing= =20 > a program. > =C2=A0At this moment I can mention three: >=20 > 1. The printer. The format of the documents you want to print must fit > on the printers available to the user. In general the problem is > solved by the possibility of printer drivers to shrink you document > f.i. from A4 to A4 or saving the document to a file that can be > printed elsewhere. This is a solved problem with PostScript; and has been for literally decade= s. > 2. The monitor on the system your program is running. Creating a window > that is to large for your screen resolution can be trouble some but > you do not know the resolution of the the customer using your > program. The solution for such a problem can only be hardware > independent programming. Your program should know the resolution of > your screen and adjust to=C2=A0 that or in the worst case decide that > system is not suitable for the program. There are similar solutions to the postscript model; hell, Borland's BGI in= the late 80s handled this problem. There was even an extension to Postscri= pt: Display PostScript. =E2=80=94 That you are having issues with this prob= lem now, after decades of experience, is illustrative of my thesis that C a= nd C++ has set the industry back decades. > 3. The available memory. Your program will in some cases need to know > the limits to which the heap stretches within the memory (in cases > where it is necessary=C2=A0 to use very large bulks of data). For > operating systems that have the possibility to stretch the heap with > a part on disc both boundaries (with and without disc data) are of > interest. Memory management is... tricky. Besides being rather technical and needing = precise adherence to a particular model, oftentimes that sort of low-level = thinking gets in your way. -- There was an excellent Guy Steele talk (I thi= nk it was "How to think about parallel programming. NOT!") where he made an= analogy between memory management and parallel processing, noting how just= as the explicit-style of earlier years (ie "put this value into a register= ") got in the way of more advanced register-allocation so too is the accumu= lator/sequential-solution going to get in the way of parallelization. > There should be a package in Ada that like GNAT.OS-lib does with=20 > operating system differences, makes such hardware parameters available=20 > for the programmer. Possibly. The problem is that there's a *LOT* of [possible] parameters, and= you'd have to multiply that by all your targets, so that's a lot of extra = work to foist on Ada implementers. =E2=80=94 I'm not saying that it isn't a= good idea, just that it's a lot of work... though this could be mitigated,= perhaps, if the Ada/OS interfaces weren't sometimes done the stupid way ar= ound (eg directory-paths as strings rather than as lists).