for S'Image use Func??
in [ADA]
|
Prev: Question about default discriminants and mutable objects.
Next: Why is not Stream_Access defined Ada.Streams ?
From: Jeffrey R. Carter on 8 May 2010 20:31 Randy Brukardt wrote: > > I'm an antique: I still type all of my message (other than part I'm replying > to) by hand. That includes the signature. "Randy." is easy enough to type; a > complex signature isn't. I gather that I'm older than you; there's hope for you yet. -- Jeff Carter "Why, the Mayflower was full of Fireflies, and a few horseflies, too. The Fireflies were on the upper deck, and the horseflies were on the Fireflies." Duck Soup 95
From: Charmed Snark on 10 May 2010 11:16 expounded in news:Pine.LNX.4.64.1005071004460.24406(a)medsec1.medien.uni- weimar.de: > On Thu, 6 May 2010, Warren wrote: > >> I'm just being a typical lazy programmer (not always >> wanting to lookup the correct package prefix for >> the To_String() function to use). > > How about overloading the &-operator: > > function "&"(S: String; Item: T) return String; > > if X is of type T and you "use type T", you can replace the expression > > T'Image(X) > > by > > "" & X > > If your T'Image(X) is part of a larger string expression, overloading & > appears to be very convenient (for the "typical lazy programmer", as > you put it): > > Ada.Text_IO.Put_Line("The first result is " & X & > " the second result is " & Y & "."); > > So long > > Stefan That's not a bad idea- thanks. Warren
From: Warren on 10 May 2010 11:48 Robert A Duff expounded in news:wccpr17yeji.fsf(a)shell01.TheWorld.com: > And teaching beginners how to instantiate generics, > when there's a simple 'Image feature, is not a good idea. > > - Bob I know how to "instantiate generics". The problem is that they don't always do what I want. Add to that, the reluctance to add bloat when there are many types involved. My biggest gripe though is with it's handling of hexadecimal. In C, I can write: sprintf(buf,"%08lX",lngval); and get my 8 digit hex value, with leading zeros (if I want it). But with the Ada supplied generics, I have to remove the "16#" and "#" from the result. So that always has me thinking, "what were they thinking?" as well. It sometimes seems that I'm always having to wrap something that the Ada standard library gives me. Another thing that bugs me is that the Ada.Text_IO will not return a LF character (like getchar() in C). IMO, there needs to be a "modernized" Ada text I/O facility. IOW something like a thick binding for the C I/O facilities but designed in Ada terms - not C terms. I know there are different flavours of C bindings for this, but without recalling the specific issues involved, I've never been real keen about using them, except as a last resort. Warren
From: Warren on 10 May 2010 12:03 Jeffrey R. Carter expounded in news:hrvg3i$2b3$1(a)tornado.tornevall.net: > Warren wrote: >> >> True, but in my case I just needed the leading zeros, sans >> any sign: >> >> 900 to be displayed as "00900" (vs " 900"). > > In my job we make extensive use of the image functions from > PragmARC.Images. These have optional Width, Base, and Zero_Filled > parameters. So we'd use Thanks for the pointer. But for my own Open Sourced project, which other folks will have to compile, I would need a very compelling reason to bring in any third party packages. This is why I am wildly enthusiastic about Ada.Containers. In the past I had to depend upon the Booch components. But then there were issues for the end user depending upon the version they chose to download and install, etc. Having Ada.Containers included, presumably means they are well supported with the compiler they have installed. So far, that has been my experience. I depend quite heavily on them for this project. So for something trivial like adding leading zeros, I won't add a "project dependency". If I further have to include patches and install instructions for same said third party packages, then that pretty much kills any interest in doing so. ;-) I vaguely remember looking at them however, back in my Ada-95 days. Warren
From: Warren on 10 May 2010 12:05
Robert A Duff expounded in news:wccd3x7lww8.fsf(a)shell01.TheWorld.com: > "Randy Brukardt" <randy(a)rrsoftware.com> writes: > >> I actually don't buy the need for the Assert pragma in the first >> place: such checks are rarely expensive and thus should simply be >> part of the code always. > > If they're not expensive, then you're not using it enough. ;-) > > Also, the other advantage of pragma Assert over an Assert > procedure is that you can put the pragma in declarative parts > and package specs. What I liked is the added convenience of having the source module and line number reported, without me having to code for that. Warren |