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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6d07d0186a356c56 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 11 Mar 2009 10:44:20 -0500 From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: Representing image data Date: Wed, 11 Mar 2009 15:45:16 +0000 Reply-To: brian@shapes.demon.co.uk Message-ID: References: <9WAtl.2301$gm6.1634@nwrddc02.gnilink.net> X-Newsreader: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-bgTTIbFgj186lQNfmuLfPBpyoXoJMHH68NrOG/T/XcsCWXD5XlkIj0olB6cRyNybzb+NnFfSeYfcsTr!COWSoQoavoKskZbaxYf+L/GO6Cz5PMgLUnPQG5lJWYKAWKjCkZlIuz0X/EOjQjSS+5KQnd50V9hN!z2g= X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: g2news1.google.com comp.lang.ada:4038 Date: 2009-03-11T15:45:16+00:00 List-Id: On Wed, 11 Mar 2009 10:00:27 +0100, "Dmitry A. Kazakov" wrote: >On Tue, 10 Mar 2009 21:26:29 GMT, Kenneth Almquist wrote: > >> I've been working on the design of an image decoding library. The >> basic idea is that the library will examine the first few bytes of >> an image, determine the format, and call the appropriate decoder, >> so that an application using the library can read images without >> writing code for each image format it wants to handle. >> >> I'm looking for suggestions on what the Ada interface to the >> library should look like--and in particular how the image contents >> should be provided to the application using the library. The current >> design has a C interface with no type checking on the image data. > >What sort of applications have you in mind? Digital filtration? Pattern >recognition? Scene analysis? Rendering? 3D simulation? ... Depending on the >application image representation format may vary. > >In any case there should be no "malloc" stuff as in your example. I would suggest ditto on the access types. And on most of the "if ... null then raise ..." These are a consequence of trying to replicate C in Ada instead of actually using the language. >> declare >> type Image_Array is ...; >> type Image_Ptr is access all Image_Array; -- declares a type rather than a variable, surely? >> begin >> Image_Ptr := malloc(Imd.Sizeof_Image(Decoder)); >> if Map_Ptr = null then raise Storage_Error; end if; ... >> Imd.Get_Image(Decoder, Image_Ptr.all'Address); I have been using the following style. I'm posting it here (a) to point the OP away from writing C in Ada and (b) on the age-old Usenet principle that the best way to elicit a smart answer is to post a dumb one... declare type Image_Array is ...; Image : Image_Array(1 to Imd.Sizeof_Image(Decoder)); -- The image size is unknown until runtime, but cannot vary within -- this declare...begin...end block -- a real solution is 2D? but 2D arrays were not C's strong point -- as Dmitry says, image representation format may vary. begin -- Space is already allocated or exception raised by this point -- Read the image. Imd.Get_Image(Decoder, Image); -- Image is an OUT parameter -- Process the image for i in Image'range loop -- process each Image(i) end loop end; This won't work for very large images (like 1GB) with Gnat on its standard settings (if the stack size is exceeded it'll just raise Storage_Error). There are apparently means of setting its stack space allocation but I haven't had any luck with them. You can explicitly set the stack size for any task other than the main task, but creating a task just to set stack size would be absurd, so I resorted to a pointer... declare type Image_Array is ...; type Image_Ptr is access all Image_Array; Image_P : Image_Ptr := new Image_Array(1 to Imd.Sizeof_Image(Decoder)); Image : Image_Array renames Image_P.all; -- now the loop body need never know about the pointer. -- It works without change whether or not you use a pointer. begin -- Read the image. Imd.Get_Image(Decoder, Image); -- Image is an OUT parameter -- Process the image -- in my application, this scope was the end of the main program. -- Other cases may need to free(Image_P) here? end; If there are better ways of accomplishing this I'm interested to hear them. - Brian