* conversion @ 2003-06-28 8:46 Andrew 2003-06-28 9:49 ` conversion Preben Randhol 2003-06-30 14:08 ` conversion Stephen Leake 0 siblings, 2 replies; 44+ messages in thread From: Andrew @ 2003-06-28 8:46 UTC (permalink / raw) To: comp.lang.ada The more I think about the string/unbounded_string inconvenience the more I think about polymorphism. Polymorphism helps readability in some situations. In the case of the 'utilities' functions I think polymorphism would provide a great service. The "flavor" that char* and char[] as parameters in functions is that they seem interchangeable. I can pass a char* into a function declared to use char[], and vice-versa. It's not that way in Ada, most likely for a real good reason, but it would sure be nice if there were a way to make it seem that easy in Ada. Enter polymorphism. If overloaded slice inside Unbounded package to return an unbounded_string an unbounded_string would still need to be created. I don't think there is any way around that part but having the overloaded slice function would bring a type transparent feeling to using the slice function and many others as well. Polymorphism in this case would help. One way to achieve polymorphism is to overload the 'utility' functions. That explains why I had the feeling of extending the functionality of the Unbounded package. It doesn't seem complete. -- In regard to separate compilation >Better to use child packages. "is separate" is really an Ada 83 >feature; child packages in Ada 95 is a better way to structure things. >Sometimes "is separate" is a good way to go, but rarely. Is the "is separate" feature going away? -- In regard to gnatmem gnatmem says it will start a program and you can provide the command line arguments to it. "gnatmem <program> <arg1> <arg2>..." So, I have a program fashionably called testprog that takes two command line arguments; a path and a filename. So I try to run gnatmem (after compiling with debug flag) like: "gnatmem testprog . testdata.txt" Gnatmem then says that the program ended unexpectedly. I can run "testprog . testdata.txt" from the command line and it works fine. -- In regard to GNAT >Hmm, this is confused. GNAT _is_ the Ada Core Technologies (ACT) >compiler. Ok, how about the IDE portion? Thanks for the help all! Andrew ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-28 8:46 conversion Andrew @ 2003-06-28 9:49 ` Preben Randhol 2003-06-30 14:08 ` conversion Stephen Leake 1 sibling, 0 replies; 44+ messages in thread From: Preben Randhol @ 2003-06-28 9:49 UTC (permalink / raw) Andrew wrote: > seem interchangeable. I can pass a char* into a function declared to > use char[], and vice-versa. It's not that way in Ada, most likely for > a real good reason, but it would sure be nice if there were a way to > make it seem that easy in Ada. Ada doesn't to implicit conversion which is a *very* good thing. -- Ada95 is good for you. http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-28 8:46 conversion Andrew 2003-06-28 9:49 ` conversion Preben Randhol @ 2003-06-30 14:08 ` Stephen Leake 1 sibling, 0 replies; 44+ messages in thread From: Stephen Leake @ 2003-06-30 14:08 UTC (permalink / raw) "Andrew" <andrew@carroll-tech.net> writes: > The more I think about the string/unbounded_string inconvenience the > more I think about polymorphism. Polymorphism helps readability in > some situations. In the case of the 'utilities' functions I think > polymorphism > would provide a great service. It would help tremendously in this discussion if you would post some actual examples. Simply stating what C does is not helpful; we need to hear what you think Ada does (so we can point out what you may be missing), and why it isn't good enough (so we can help you see why it is :). > <snip> > That explains why I had the feeling of extending the functionality of the > Unbounded > package. It doesn't seem complete. Please be specific. What features/functionality is it missing? > -- In regard to separate compilation > >Better to use child packages. "is separate" is really an Ada 83 > >feature; child packages in Ada 95 is a better way to structure things. > >Sometimes "is separate" is a good way to go, but rarely. > Is the "is separate" feature going away? No. > -- In regard to gnatmem gnatmem says it will start a program and you > can provide the command line arguments to it. "gnatmem <program> > <arg1> <arg2>..." > > So, I have a program fashionably called testprog that takes two > command line arguments; a path and a filename. So I try to run > gnatmem (after compiling with debug flag) like: > > "gnatmem testprog . testdata.txt" You'll have to post the source for testprog to get help on this one. > -- In regard to GNAT > >Hmm, this is confused. GNAT _is_ the Ada Core Technologies (ACT) > >compiler. > Ok, how about the IDE portion? In addition to the compiler, ACT also produces two IDE's; GLIDE and GPS. GLIDE is a minor enhancement and packaging of Gnu Emacs, and is a very good IDE; I use Gnu Emacs (but not the GLIDE packaging) for all work, mainly because I can customize it to do _exactly_ what I want it to do, partly because it is available on _every_ operating system I care about (Windows, Linux, Lynx, Solaris, etc.). GPS is a new IDE (there is not yet a public release). It uses the Gtk GUI library, and is therefore portable across MS Windows and X-Windows (but not Lynx, yet). It is not as powerful as Gnu Emacs, and has limited user customizations. It is definitely a work in progress; the goal is to compete with MS Visual Studio etc. GPS will be eaiser to learn than GLIDE for people who are used to IDE's such as MS Visual Studio or Borland; GLIDE will be easier to learn for people who are familiar with any flavor of Emacs. There is also a small IDE called AdaGide; it is intended for student use, and has very limited functionality. It is not produced by ACT, but by a group at the Air Force Academy (I believe). -- -- Stephe ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <002701c33e22$8e9deaf0$0201a8c0@win>]
* Re: conversion [not found] <002701c33e22$8e9deaf0$0201a8c0@win> @ 2003-06-29 20:15 ` David C. Hoos, Sr. 0 siblings, 0 replies; 44+ messages in thread From: David C. Hoos, Sr. @ 2003-06-29 20:15 UTC (permalink / raw) To: Andrew, comp.lang.ada ----- Original Message ----- From: "Andrew" <andrew@carroll-tech.net> To: <comp.lang.ada@ada.eu.org> Sent: June 29, 2003 4:41 AM Subject: conversion > Just out of curiosity; what would be wrong with moving string into it's own > package? Lack of backward compatibility. > > Andrew > > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* conversion @ 2003-06-29 9:41 Andrew 2003-07-04 10:42 ` conversion Janeit 0 siblings, 1 reply; 44+ messages in thread From: Andrew @ 2003-06-29 9:41 UTC (permalink / raw) To: comp.lang.ada Just out of curiosity; what would be wrong with moving string into it's own package? Andrew ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-29 9:41 conversion Andrew @ 2003-07-04 10:42 ` Janeit 0 siblings, 0 replies; 44+ messages in thread From: Janeit @ 2003-07-04 10:42 UTC (permalink / raw) I like to use the package Ustrings. Mirrored on my site and taken from the cgi binding I find it very useful. location: http://www.noam.nl/download/ada95/ustrings.adb http://www.noam.nl/download/ada95/ustrings.ads "Andrew" <andrew@carroll-tech.net> schreef in bericht news:mailman.0.1056888878.2855.comp.lang.ada@ada.eu.org... > Just out of curiosity; what would be wrong with moving string into it's own > package? > > Andrew > ^ permalink raw reply [flat|nested] 44+ messages in thread
* conversion @ 2003-06-27 17:37 Andrew 2003-06-27 17:32 ` conversion Stephen Leake 2003-06-28 2:55 ` conversion Jeffrey Carter 0 siblings, 2 replies; 44+ messages in thread From: Andrew @ 2003-06-27 17:37 UTC (permalink / raw) To: comp.lang.ada Ok, so I found the ada.strings.unbounded package spec and body and took a look at the definition and implementation of unbounded string. Finally I found them! Unbounded_string is basically an object that contains a reference to a string. It would be something like: typdef struct unbounded_string{ char* reference; } with methods to manipulate the structure. My example may not be syntactically correct but I think I convey the basic idea. String is an array, Unbounded_String is an "object" that contains a reference to an array. So...The conversion from Unbounded_String to String is pretty easy. Return the pointer de-reference. From String to Unbounded_String is the expensive one. In general it is: allocate memory copy values from old to new return the new. So, using unbounded and calling to_string is relatively fast. Good, I'm satisfied with that part. I think it would be easy enough to create a slice and trim method that returned an unbounded_string so that I would not have to use the expensive string to unbounded_string conversion and that nagging inconvenience would be pacified. Dmitry mentioned that get_line reads in to a string buffer. Then after the line was read another string could be made because the last parameter is the length of what was read. Your absolutely right! I knew that and looked right over it. It wasn't hard at all to write a program that uses to_string and to_unbounded_string. It works. It's just that I didn't realize in design that I would need so many conversions and I wasn't fluent enough with all the "utility" methods like slice, trim, head, etcetera to really specify at design time whether I needed String or Unbounded_String. Once implementation time came up I almost immediately had to go back to design because I was introducing so much code for the conversions. I thought "there has to be a better way". Something else I really like about Ada is separate compilation. I can separate subprocedures into other files with the "is separate" and Separate(<name>) feature. That one thing would make code SO much more manageable. I could spread that thing out and assign tasks by function if needed. Then, just compile! I also was trying to get gnatmem to run but it fails. Has anyone used the Ada Core Technologies compiler? How does it compare to the public GNAT that I'm using; comes with FreeBSD Unix. Thanks for the help! Andrew ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 17:37 conversion Andrew @ 2003-06-27 17:32 ` Stephen Leake 2003-06-28 2:55 ` conversion Jeffrey Carter 1 sibling, 0 replies; 44+ messages in thread From: Stephen Leake @ 2003-06-27 17:32 UTC (permalink / raw) "Andrew" <andrew@carroll-tech.net> writes: > Ok, so I found the ada.strings.unbounded package spec and body and > took a look at the definition and implementation of unbounded > string. Finally I found them! ok. > <snip> > So...The conversion from Unbounded_String to String is pretty easy. > Return the pointer de-reference. Yes. > From String to Unbounded_String is the expensive one. In general it > is: allocate memory copy values from old to new return the new. Yes. > So, using unbounded and calling to_string is relatively fast. Good, > I'm satisfied with that part. Ok. > I think it would be easy enough to create a slice and trim method > that returned an unbounded_string so that I would not have to use > the expensive string to unbounded_string conversion and that nagging > inconvenience would be pacified. What is your application? There are many other ways to represent pieces of strings. For example, you can store a string and a bunch of indexes into the string. > It wasn't hard at all to write a program that uses to_string and > to_unbounded_string. It works. Good. > It's just that I didn't realize in design that I would need so many > conversions and I wasn't fluent enough with all the "utility" > methods like slice, trim, head, etcetera to really specify at design > time whether I needed String or Unbounded_String. Once > implementation time came up I almost immediately had to go back to > design because I was introducing so much code for the conversions. Yes, this is often the case when learning new utilities. My rule is that the design isn't right until you've redone it three times. > I thought "there has to be a better way". You'll get there :). > Something else I really like about Ada is separate compilation. I > can separate subprocedures into other files with the "is separate" > and Separate(<name>) feature. That one thing would make code SO much > more manageable. I could spread that thing out and assign tasks by > function if needed. Then, just compile! Better to use child packages. "is separate" is really an Ada 83 feature; child packages in Ada 95 is a better way to structure things. Sometimes "is separate" is a good way to go, but rarely. > I also was trying to get gnatmem to run but it fails. Give an example of the code and error message; maybe I can help. > Has anyone used the Ada Core Technologies compiler? Yes. > How does it compare to the public GNAT that I'm using; comes with > FreeBSD Unix. Hmm, this is confused. GNAT _is_ the Ada Core Technologies (ACT) compiler. ACT is constantly developing the compiler; when they get a reasonably stable new version, they release it to their supported customers. After the supported customers have time to find some more bugs, they release it to the public. Then there is the version of GNAT bundled with the GCC release. ACT calls that 5.01w; gcc calls it 3.1. It is _not_ as well tested as the public ACT release. So as a supported customer, I'm using GNAT 3.16a. The one that comes with FreeBSD Unix may be 3.15p, or 3.1. Yes, it is confusing. But they are all versions of the same compiler. -- -- Stephe ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 17:37 conversion Andrew 2003-06-27 17:32 ` conversion Stephen Leake @ 2003-06-28 2:55 ` Jeffrey Carter 1 sibling, 0 replies; 44+ messages in thread From: Jeffrey Carter @ 2003-06-28 2:55 UTC (permalink / raw) Andrew wrote: > Ok, so I found the ada.strings.unbounded package spec and body and took a > look > at the definition and implementation of unbounded string. Finally I found > them! > > Unbounded_string is basically an object that contains a reference to a > string. What you are discussing is one specific compiler's implementation of Ada.Strings.Unbounded.Unbounded_String. Other compilers may use other implementations. This may seem unlikely, but some compilers might treat objects of this type as a special case in order to speed up the memory management required for them. Ada has so many ways to use type String that there are few cases when a variable-length string type is really needed. Many cases where other languages need a variable string can be handled very easily by Ada's type String, and many uses of Unbounded_String in Ada are more examples of laziness or unfamiliarity with Ada's capabilities than of a real need for a variable string. This is similar to the case of pointers. Access types are needed much more rarely in Ada than in many other languages, especially C. People who are using a lot of access types, objects, and values in Ada are probably using the language ineffectively, frequently because that's the way they're used to doing things in other languages. -- Jeff Carter "I'm a lumberjack and I'm OK." Monty Python's Flying Circus ^ permalink raw reply [flat|nested] 44+ messages in thread
* conversion @ 2003-06-27 10:51 Andrew 2003-06-27 12:22 ` conversion Dmitry A. Kazakov ` (5 more replies) 0 siblings, 6 replies; 44+ messages in thread From: Andrew @ 2003-06-27 10:51 UTC (permalink / raw) To: comp.lang.ada I am experimenting with Ada as the primary language in our process. It seems that the use of String and Unbounded_String require converting from one to the other in order to read a line from a file and then trim it or slice it or tokenize it. For now, regardless of the performance of these conversions it is rather inconvenient to design for a language that does not have a "universal" string type. For instance: a variable of type char * can be used as char * or as char [] and char [] can be used as char *. A fixed string in Ada (to me) is like declaring a char [], you must specify a size at compile time. An unbounded_string in Ada is like char *, it can take on a different size when it appears on the LHS of an assignment operator. The catch is that unbounded_string can not be used in context of string. This posses some design inconveniences and requires converting back and forth from string to unbounded_string multiple times. I defined a string pointer type so that I could dynamically create strings that are the fixed string type but I find that 'that' only defers the need to convert from fixed string to unbounded_string to different points in the design or that the conversion is not eliminated. I am now thinking that for my company we could develop a "library" that has a "universal" string type. If we don't base it on the defined string in package standard and can use streams to read from files then we can define our own string type. I think... I'm not real sure whether to extend on the functionality of ada.text_io or to create new functionality from the stream package. Any recommendations? Has anyone done something like this? Andrew ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 10:51 conversion Andrew @ 2003-06-27 12:22 ` Dmitry A. Kazakov 2003-06-27 12:37 ` conversion Stephen Leake ` (4 subsequent siblings) 5 siblings, 0 replies; 44+ messages in thread From: Dmitry A. Kazakov @ 2003-06-27 12:22 UTC (permalink / raw) On Fri, 27 Jun 2003 04:51:04 -0600, "Andrew" <andrew@carroll-tech.net> wrote: >I am experimenting with Ada as the primary language in our process. It >seems that >the use of String and Unbounded_String require converting from one to the >other in >order to read a line from a file and then trim it or slice it or tokenize >it. Usually you do not need Unbounded_String when you are working with files. You read into a string buffer and parse the buffer contents taking into account the number of read characters. Ada.Text_IO.Get_Line uses this technique: procedure Get_Line ( File : in File_Type; Item : out String; Last : out Natural ); When you parse the buffer, the recognized tokens need not to be copied. You can well use string slices for that. >For now, >regardless of the performance of these conversions it is rather inconvenient >to design >for a language that does not have a "universal" string type. Yes, Unbounded_String and String should to be siblings, which is presently impossible in Ada. >For instance: a variable of type char * can be used as char * or as char [] >and char [] >can be used as char *. A fixed string in Ada (to me) is like declaring a >char [], you >must specify a size at compile time. An unbounded_string in Ada is like >char *, it can >take on a different size when it appears on the LHS of an assignment >operator. The >catch is that unbounded_string can not be used in context of string. This >posses some >design inconveniences and requires converting back and forth from string to >unbounded_string multiple times. In most cases you can avoid Unbounded_String by using discriminated types: type Employee (Name_Length : Positive) is record Name : String (1..Name_Length); ... end record; Truly dynamic string objects are surprisingly rare. Even if you have such, they will be likely encapsulated in more complex objects, for which it should be no problem to define an appropriate interface in terms of Strings not Unbounded_Strings. >I defined a string pointer type so that I could dynamically create strings >that are the fixed >string type but I find that 'that' only defers the need to convert from >fixed string to >unbounded_string to different points in the design or that the conversion is >not eliminated. I presume that Unbounded_String-->String conversion is very inexpensive. >I am now thinking that for my company we could develop a "library" that has >a "universal" >string type. If we don't base it on the defined string in package standard >and can use >streams to read from files then we can define our own string type. I >think... > >I'm not real sure whether to extend on the functionality of ada.text_io or >to create new >functionality from the stream package. Any recommendations? Has anyone >done >something like this? I never felt any need in something like that. Perhaps others ... --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 10:51 conversion Andrew 2003-06-27 12:22 ` conversion Dmitry A. Kazakov @ 2003-06-27 12:37 ` Stephen Leake 2003-06-27 14:26 ` conversion Bill Findlay 2003-06-27 13:25 ` conversion Robert I. Eachus ` (3 subsequent siblings) 5 siblings, 1 reply; 44+ messages in thread From: Stephen Leake @ 2003-06-27 12:37 UTC (permalink / raw) "Andrew" <andrew@carroll-tech.net> writes: > I am experimenting with Ada as the primary language in our process. > It seems that the use of String and Unbounded_String require > converting from one to the other in order to read a line from a file > and then trim it or slice it or tokenize it. The "correct" choice of what to do depends heavily on exactly what your application is. If you are writing a tokenizer, you should consider using OpenToken. > For now, regardless of the performance of these conversions it is > rather inconvenient to design for a language that does not have a > "universal" string type. Yes, it is sometimes difficult to decide which of Ada's many features to use. It's much easier in C, where you have no choice :). > For instance: a variable of type char * can be used as char * or as > char [] and char [] can be used as char *. yes. > A fixed string in Ada (to me) is like declaring a char [], you must > specify a size at compile time. Yes. > An unbounded_string in Ada is like char *, it can take on a > different size when it appears on the LHS of an assignment operator. No. The best analogy to char * is Ada.Strings.Unbounded.String_Access; a pointer to an allocated string. C does _not_ have a true unbounded string type, that can automatically change size; you have to free and reallocate. C++ provides a String class that behaves much like Ada's Unbounded_String. > The catch is that unbounded_string can not be used in context of > string. That's what To_String is for. You should not worry about whether that is "efficient". When you have finished you application, if it is too slow, you can measure it's speed, find the bottlenecks, and fix them. I'd be very surprised if To_String is a bottleneck. > This posses some design inconveniences and requires converting back > and forth from string to unbounded_string multiple times. That does sound like a problem. Perhaps you could give more details, and we could provide better advice. You could also measure the speed of the conversions now, to convince yourself that it is (or is not) a problem. > I defined a string pointer type so that I could dynamically create > strings that are the fixed string type but I find that 'that' only > defers the need to convert from fixed string to unbounded_string to > different points in the design or that the conversion is not > eliminated. There are many ways to avoid the need for unbounded strings, typicallly using a local declare block. However, there are also times when you need them, typically when storing strings in records. How would you solve the problem in C? If you are happy with that solution, do exactly the same thing in Ada, with the mapping char[] => String, char * => String_Access, malloc => new, free => Unchecked_Conversion. > I am now thinking that for my company we could develop a "library" > that has a "universal" string type. If we don't base it on the > defined string in package standard and can use streams to read from > files then we can define our own string type. I think... What features would this "universal" string type have that either String or Unbounded_String does not have? > I'm not real sure whether to extend on the functionality of > ada.text_io What is missing from Ada.Text_IO? > or to create new functionality from the stream package. Any > recommendations? Has anyone done something like this? Many people have complained about Ada strings. They do take getting used to, especially if you are coming from a C (rather than C++) background. But no one has proposed a better solution (to my knowledge). Hmm, Matthew Heaney's Charles library has a new String type, but I haven't looked at it to see why. -- -- Stephe ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 12:37 ` conversion Stephen Leake @ 2003-06-27 14:26 ` Bill Findlay 2003-06-27 17:04 ` conversion Georg Bauhaus 2003-07-04 0:21 ` conversion Dave Thompson 0 siblings, 2 replies; 44+ messages in thread From: Bill Findlay @ 2003-06-27 14:26 UTC (permalink / raw) On 27/6/03 13:37, in article uznk3u258.fsf@nasa.gov, "Stephen Leake" <Stephe.Leake@nasa.gov> wrote: > "Andrew" <andrew@carroll-tech.net> writes: >> A fixed string in Ada (to me) is like declaring a char [], you must >> specify a size at compile time. > > Yes. Actually, no. The size of a fixed string is determined when its declaration is elaborated. You specify the index subtype bounds (and hence the size) at run time. The bound values need not be known at compile time, although they may be. I'm not being pedantic, this is a surprise to many C* programmers. In the case of a local string variable, it may take a different size each time its scope is entered, e.g.: function f (n : positive) return String is s : String(1..n) := (others => ' '); begin if n > 1 then return s & f(n-1); end if; return s; end f; This returns a blank string of length n(n+1)/2. -- Bill-Findlay chez blue-yonder.co.uk ("-" => "") ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 14:26 ` conversion Bill Findlay @ 2003-06-27 17:04 ` Georg Bauhaus 2003-07-04 0:21 ` conversion Dave Thompson 1 sibling, 0 replies; 44+ messages in thread From: Georg Bauhaus @ 2003-06-27 17:04 UTC (permalink / raw) Bill Findlay <yaldnifw@blueyonder.co.uk> wrote: :> "Andrew" <andrew@carroll-tech.net> writes: : : function f (n : positive) return String is : s : String(1..n) := (others => ' '); : begin : if n > 1 then return s & f(n-1); end if; : return s; : end f; : : This returns a blank string of length n(n+1)/2. You can combine this with Get_Line and then Find_Token. Georg ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 14:26 ` conversion Bill Findlay 2003-06-27 17:04 ` conversion Georg Bauhaus @ 2003-07-04 0:21 ` Dave Thompson 1 sibling, 0 replies; 44+ messages in thread From: Dave Thompson @ 2003-07-04 0:21 UTC (permalink / raw) On Fri, 27 Jun 2003 15:26:36 +0100, Bill Findlay <yaldnifw@blueyonder.co.uk> wrote: > On 27/6/03 13:37, in article uznk3u258.fsf@nasa.gov, "Stephen Leake" > <Stephe.Leake@nasa.gov> wrote: > > > "Andrew" <andrew@carroll-tech.net> writes: > >> A fixed string in Ada (to me) is like declaring a char [], you must > >> specify a size at compile time. > > I would say C char[] is kind of in-between Ada (fixed) String and Bounded_String. Yes the space allocated is fixed, at compile time or at best at "elaboration" time (below), but a string value within it is by convention null-terminated and (thus) variable up to the allocated size minus one. > > Yes. > > Actually, no. > The size of a fixed string is determined when its declaration is elaborated. > > You specify the index subtype bounds (and hence the size) at run time. > The bound values need not be known at compile time, although they may be. > C99 does allow array size of locals to be determined at runtime; they are called Variable Length Arrays. You cannot choose lowerbound, as you cannot for any array in C, although for strings that is rarely a big issue. You still aren't guaranteed, and rarely if ever get, bounds checking, or even stack overflow checking. And C99 isn't widely implemented yet, although this particular feature is already available in gcc and has been for some years as an extension. It's not clear if this will be picked up by C++, especially since as noted elsethread they already have std::string. > I'm not being pedantic, this is a surprise to many C* programmers. > > In the case of a local string variable, it may take a different size each > time its scope is entered, e.g.: > > function f (n : positive) return String is > s : String(1..n) := (others => ' '); > begin > if n > 1 then return s & f(n-1); end if; > return s; > end f; > > This returns a blank string of length n(n+1)/2. But in C you (still) can't return, or assign or pass as (value) argument, _any_ array, string or otherwise; trying to do so at most sets a pointer; and returning a pointer to local space, which becomes invalid on the return, is a dangerous error -- which some C compilers will even diagnose! - David.Thompson1 at worldnet.att.net ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 10:51 conversion Andrew 2003-06-27 12:22 ` conversion Dmitry A. Kazakov 2003-06-27 12:37 ` conversion Stephen Leake @ 2003-06-27 13:25 ` Robert I. Eachus 2003-06-27 18:42 ` conversion tmoran 2003-06-27 14:49 ` conversion Matthew Heaney ` (2 subsequent siblings) 5 siblings, 1 reply; 44+ messages in thread From: Robert I. Eachus @ 2003-06-27 13:25 UTC (permalink / raw) Andrew wrote: > I am experimenting with Ada as the primary language in our process. It > seems that the use of String and Unbounded_String require converting > from one to the other in order to read a line from a file and then > trim it or slice it or tokenize it. For now, regardless of the > performance of these conversions it is rather inconvenient to design > for a language that does not have a "universal" string type. > > For instance: a variable of type char * can be used as char * or as > char [] and char [] can be used as char *. A fixed string in Ada (to me) > is like declaring a char [], you must specify a size at compile time. An > unbounded_string in Ada is like char *, it can take on a different size > when it appears on the LHS of an assignment operator. The catch is that > unbounded_string can not be used in context of string. This posses some > design inconveniences and requires converting back and forth from string to > unbounded_string multiple times. > > I defined a string pointer type so that I could dynamically create strings > that are the fixed string type but I find that 'that' only defers the need > to convert from fixed string to unbounded_string to different points in the > design or that the conversion is not eliminated. I am now thinking that for > my company we could develop a "library" that has a "universal" string type. > If we don't base it on the defined string in package standard and can use > streams to read from files then we can define our own string type. I > think... > > I'm not real sure whether to extend on the functionality of ada.text_io or > to create new functionality from the stream package. Any recommendations? > Has anyone done something like this? > > Andrew Hmmm. Where to begin. You are thinking in C about Ada concepts. That is confusing you because the Ada mappings are different. In Ada, the TYPE String is unconstrained. Objects must be constrained, so if you need to put a String somewhere, you have to provide a constraint, explicitly or implicitly. If you do: Foo: String := Bar; The object Foo is constrained to the length of the String returned by the call to Bar (if Bar is a function), or to have the same length as Bar, if Bar is an object. In C, you can have objects of type char [], but you can't have values of char []. So parameters of char [] are implicitly converted to char *. In Ada, you almost never need an access to String type. You can create one, or use the one defined in Ada.Strings.Unbounded, but it just muddies up the waters. So what is Ada.Strings.Unbounded.Unbounded_String? Conceptually all you need to know is that it is a (constrained) container type, so you can have objects of type Ada.Strings.Unbounded_String. Putting strings into a container should be less expensive than malloc and free in C. (Or I guess free and malloc in this case.) Using the String VALUE that is in an Unbounded_String container is no harder than using any other value. So in Ada, 99% of the time when you need to use a (lower case) string type, you use String, and done. If for some reason you need a string object that can vary within bounds (like PL/I char * varying) or a string object whose bounds can vary radically, you create an instance of Ada.Strings.Bounded_String, or use Ada.Strings.Unbounded_String. Ada.Strings.Unbounded_String has no counterpart that I am aware of outside garbage collected languages. It does automatic string allocation and storage management at a very low cost. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 13:25 ` conversion Robert I. Eachus @ 2003-06-27 18:42 ` tmoran 0 siblings, 0 replies; 44+ messages in thread From: tmoran @ 2003-06-27 18:42 UTC (permalink / raw) >Hmmm. Where to begin. You are thinking in C about Ada concepts. That >is confusing you because the Ada mappings are different. In Ada, the As a general rule, if something seems inordinately hard to do in Ada, you are probably not using Ada appropriately. In the case of strings, declaring dynamically sized strings, passing strings as dynamically sized parameters, using concatenation, and, especially, using slices will handle a great many string processing tasks. eg, procedure Process_Line(Line : in String) is -- From "Fred Smith #12345; John Jones, Albert" -- make 2 calls on Process_First_Name -- Process_Full_Name("Smith, Fred"); -- Process_Full_Name("Jones, John"); First, Last : Natural; begin First := Line'first; loop Ada.Strings.Fixed.Find_Token (Source=>Line(First .. Line'last), Set =>Ada.Strings.Maps.Constants.Letter_Set, Test =>Ada.Strings.Inside, First =>First, Last =>Last); exit when Last = 0; declare use Ada.Strings; use Ada.Strings.Maps.Constants; First_Name : String renames Line(First .. Last); begin Fixed.Find_Token(Line(Last+1 .. Line'last), Letter_Set, Inside, First, Last); exit when Last = 0; Process_Full_Name(Line(First .. Last) & ", " & First_Name); end; First := Last+1; end loop; end Process_Line; ... Line : String(1 .. 80); Last : Natural; ... Ada.Text_IO.Get_Line(Input, Line, Last); Process_Line(Line(Line'first .. Last)); ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 10:51 conversion Andrew ` (2 preceding siblings ...) 2003-06-27 13:25 ` conversion Robert I. Eachus @ 2003-06-27 14:49 ` Matthew Heaney 2003-06-27 17:10 ` conversion Georg Bauhaus 2003-06-27 17:13 ` conversion Alexander Kopilovitch 5 siblings, 0 replies; 44+ messages in thread From: Matthew Heaney @ 2003-06-27 14:49 UTC (permalink / raw) "Andrew" <andrew@carroll-tech.net> wrote in message news:<mailman.18.1056709818.8204.comp.lang.ada@ada.eu.org>... > > I'm not real sure whether to extend on the functionality of ada.text_io or > to create new > functionality from the stream package. Any recommendations? Has anyone > done > something like this? GNAT has added a child package to Text_IO to add support for reading into an unbounded_string directly. It has also added a child packet to Ada.Strings.Unbounded, to return a pointer to the underlying string. This will make conversions from unbounded_string to string more efficient. The Charles library also has a string container package, that provides a similar function to return a pointer to the underlying string. It would be simple enough (and also more efficient) to add a child package (did I do it already?) to read into an unbounded string container type directly. http://home.earthlink.net/~matthewjheaney/charles/ I'll have a new release of the charles library probably later today (Fri, 27 June 2003). If there's something you need right away maybe I can fold it into today's release. Realize that you have a similar issue in C++, because you have both type char* and class std::string. The std::string class has a member function c_str() that allocs a const char* array containing the current value of the string. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 10:51 conversion Andrew ` (3 preceding siblings ...) 2003-06-27 14:49 ` conversion Matthew Heaney @ 2003-06-27 17:10 ` Georg Bauhaus 2003-06-27 17:13 ` conversion Alexander Kopilovitch 5 siblings, 0 replies; 44+ messages in thread From: Georg Bauhaus @ 2003-06-27 17:10 UTC (permalink / raw) Andrew <andrew@carroll-tech.net> wrote: : For instance: a variable of type char * can be used as char * or as char [] : and char [] : can be used as char *. As an aside, Ada's strings might turn out to be helpful in situations like char s[SZ]; // ... char* t = (char*)malloc(100); // ... strncpy(s, t, SZ); for a few reasons. georg ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 10:51 conversion Andrew ` (4 preceding siblings ...) 2003-06-27 17:10 ` conversion Georg Bauhaus @ 2003-06-27 17:13 ` Alexander Kopilovitch 2003-06-27 17:34 ` conversion Preben Randhol 2003-06-27 22:13 ` conversion Robert I. Eachus 5 siblings, 2 replies; 44+ messages in thread From: Alexander Kopilovitch @ 2003-06-27 17:13 UTC (permalink / raw) >The catch is that unbounded_string can not be used in context of string. >This posses some design inconveniences and requires converting back and forth >from string to unbounded_string multiple times. Exactly. This is very inconvenient (perhaps, most inconvenient) feature of Ada language. Certainly, a chorus tells you that Ada is not C, but what about Pascal, which has much more resemblance with Ada? Pascal isn't C, it does not rely heavily upon pointers, but at the same time it has quite good and usable strings. The chorus also tells you that in Ada you should not need those conversion too often. Well, they are honest enough, they simply do not use Ada for a job and in an environment where you must mix varying strings and constant strings here and there, and at the same time you can't afford several weeks for design for every change in specifications. Ada simply understimates need of strings in non-numerical world (almost like Fortran IV, that is, before Fortran 77). I'm sure that Ada people would cry very loudly if there were similar situation with Integer type: imagine that there is unconstrained (for value, not for storage size) type Integer, which objects must be constrained (by value). Then, there are types Bounded_Integer and Unbounded_Integer. Unbounded_Integer is good for general use, except that you always have to write explicit conversion when you assign a literal (say, 1 or 0) to an object of Unbounded_Integer type (currently Ada Integer is like a Pascal string in this respect). Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 17:13 ` conversion Alexander Kopilovitch @ 2003-06-27 17:34 ` Preben Randhol 2003-06-27 22:10 ` conversion Alexander Kopilovitch 2003-06-27 22:13 ` conversion Robert I. Eachus 1 sibling, 1 reply; 44+ messages in thread From: Preben Randhol @ 2003-06-27 17:34 UTC (permalink / raw) Alexander Kopilovitch wrote: > Certainly, a chorus tells you that Ada is not C, but what about Pascal, which > has much more resemblance with Ada? Pascal isn't C, it does not rely heavily > upon pointers, but at the same time it has quite good and usable strings. Oh I remembered when we had to use Pascal in some introductory programming course at the university that there was several machines crashing due to that the students didn't get the pointers correctly. -- Ada95 is good for you. http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 17:34 ` conversion Preben Randhol @ 2003-06-27 22:10 ` Alexander Kopilovitch 2003-06-28 9:46 ` conversion Preben Randhol 0 siblings, 1 reply; 44+ messages in thread From: Alexander Kopilovitch @ 2003-06-27 22:10 UTC (permalink / raw) Preben Randhol wrote: > > Certainly, a chorus tells you that Ada is not C, but what about Pascal, which > > has much more resemblance with Ada? Pascal isn't C, it does not rely heavily > > upon pointers, but at the same time it has quite good and usable strings. > >Oh I remembered when we had to use Pascal in some introductory >programming course at the university that there was several machines >crashing due to that the students didn't get the pointers correctly. Is it all you remember about Pascal? If so that, perhaps, you should not be much surprised when other people associate Ada with Ariane 5 crash only. Anyway, why you switched to the Pascal pointers from the theme of strings? Pascal is not C, and Pascal strings aren't naturally associated with pointers. Finally, as you mention those dangerous pointers in Pascal, let me quote the "Programming in Ada 95" by John Barnes (2nd edition, 1998), Chapter 10, Access Types, p.171 : "Playing with pointers is like playing with fire. Fire is perhaps the most important tool known to man. Carefully used, fire brings enormous benefits, but when fire gets out of control, disaster strikes. Pointers have similar characteristics but are well tamed in the form of access types in Ada." Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 22:10 ` conversion Alexander Kopilovitch @ 2003-06-28 9:46 ` Preben Randhol 0 siblings, 0 replies; 44+ messages in thread From: Preben Randhol @ 2003-06-28 9:46 UTC (permalink / raw) Alexander Kopilovitch wrote: > Preben Randhol wrote: > >> > Certainly, a chorus tells you that Ada is not C, but what about >> > Pascal, which has much more resemblance with Ada? Pascal isn't C, >> > it does not rely heavily upon pointers, but at the same time it has >> > quite good and usable strings. >> >>Oh I remembered when we had to use Pascal in some introductory >>programming course at the university that there was several machines >>crashing due to that the students didn't get the pointers correctly. > > Is it all you remember about Pascal? If so that, perhaps, you should > not be much surprised when other people associate Ada with Ariane 5 > crash only. I also remember problematic syntax where you should not put ";" in some cases. This most students got wrong. Anyway it has been 10 years since I look at Pascal, but I think I should be able to read it. > Anyway, why you switched to the Pascal pointers from the theme of > strings? Pascal is not C, and Pascal strings aren't naturally > associated with pointers. No, I was commenting on what was written (se above) about pointer. I didn't say Pascal didn't have good strings as I don't remember how they worked now. Must look it up. > Finally, as you mention those dangerous pointers in Pascal, let me > quote the "Programming in Ada 95" by John Barnes (2nd edition, 1998), > Chapter 10, Access Types, p.171 : > > "Playing with pointers is like playing with fire. Fire is perhaps the > most important tool known to man. Carefully used, fire brings enormous > benefits, but when fire gets out of control, disaster strikes. > Pointers have similar characteristics but are well tamed in the form > of access types in Ada." Yes? Not sure I see your point with this quote though. Preben -- Ada95 is good for you. http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 17:13 ` conversion Alexander Kopilovitch 2003-06-27 17:34 ` conversion Preben Randhol @ 2003-06-27 22:13 ` Robert I. Eachus 2003-06-30 8:52 ` conversion Dmitry A. Kazakov 2003-07-05 2:40 ` conversion Alexander Kopilovitch 1 sibling, 2 replies; 44+ messages in thread From: Robert I. Eachus @ 2003-06-27 22:13 UTC (permalink / raw) Alexander Kopilovitch wrote: > The chorus also tells you that in Ada you should not need those conversion > too often. Well, they are honest enough, they simply do not use Ada for > a job and in an environment where you must mix varying strings and constant > strings here and there, and at the same time you can't afford several weeks > for design for every change in specifications. > > Ada simply understimates need of strings in non-numerical world (almost like > Fortran IV, that is, before Fortran 77). I'm sure that Ada people would cry > very loudly if there were similar situation with Integer type: imagine that > there is unconstrained (for value, not for storage size) type Integer, which > objects must be constrained (by value). Then, there are types Bounded_Integer > and Unbounded_Integer. Unbounded_Integer is good for general use, except that > you always have to write explicit conversion when you assign a literal (say, > 1 or 0) to an object of Unbounded_Integer type (currently Ada Integer is like > a Pascal string in this respect). This is silly. The situation in Ada is exactly the same with integer and string types. Objects must be constrained, values need not be. If I write: X: Integer; ... X := X + 1; ... the result may not fit in an Integer and I'll get Constraint_Error. But the Constraint_Error occurs because of this value/object dichotomy, just as if I had tried to assign an 81 character string to an 80 character buffer. The Ada.Strings.Bounded and Ada.Strings.Unbounded packages provide a way to create objects that have only a maximum or no minimum and no maximum length respectively. The equivalent for integer types is a bignum package, which supports any size integer value without Constraint_Error. Now compile and run this code: with Ada.Text_IO; use Ada.Text_IO; procedure NumEx is X: Integer := 2**65 / 3**38 + 3; begin Put_Line("The value of X is" & Integer'Image(X)); end NumEx; If it doesn't compile without error and print: The value of X is 30 Send a bug report to the compiler vendor. What happened there? If you don't see why there would be a problem in most languages, go back and look more carefully. I'll wait. I suspect that 2**65 is out of range for any predefined integer type for your compiler. (If it isn't, make up your own example.) This behaviour is required by RM 8.6(29) which states a preference for operations for root integer and root real. These rules require every Ada compiler to implement a bignum package and a rational arithmetic package and use them at compile time in some cases. If you are a language lawyer, you should know how to "take advantage" of these special rules to do (numerical) things in Ada. Of course, if you need unbounded rational arithmetic objects not values, the best way is to snarf the rational arithmetic package from the compiler. It isn't as easy to use as using Integer--for exactly the same reasons that using Unbounded_String is not quite as easy as using String. Of course, as I showed above, you can use these exended arithmetic features of Ada very easily and not really know that you are doing it. To sum up, everything you can do with char[] and char* in C can be done in Ada with String. There are things you can do with String in Ada that are not possible in C. (Of course, in the sense that both languages are Turing complete, that isn't true, but you get my meaning.) There are things you can do in PL/I with char * varying, that you can do in Ada with Ada.Strings.Bounded. There are things that you can do in C++ with the class str that you can do in Ada with Ada.Strings.Unbounded. If you are bugged by writing To_String, and To_Unbounded_String, go ahead and create your own functions. THERE IS A BIG CATCH HERE. But let me show you what I mean. First, look at all the functions that are available in Ada.Strings.Unbounded. There is a lot of unexpected wealth there. For example: with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; with Ada.Text_IO; use Ada.Text_IO; procedure Fun is U1: Unbounded_String := 3 * 'A'; U2: Unbounded_String := 2 * "can"; S1: String := " dance"; function "&"(L: String; R: Unbounded_String) return String is begin return L & To_String(R); end "&"; begin Put_Line(" U1 is " & U1); Put_Line(" U2 is " & U2); Put_Line(" U2 & S1 is " & U2 & S1); end Fun; So what is the catch? Notice that I only created one new "&" operation, if I had added: function "&"(L: Unbounded_String; R: String) return String is begin return To_String(L) & R; end "&"; as well, then the program wouldn't have compiled. I could use a qualified expression inside the third Put_Line to determine which "&" functions got called, but best is not to have too may operators floating around. Adding one or two can really help clean up your code, adding too many leads to madness. Personally I think that the functions that return String are more useful, so I could have avoided a use clause for Ada.Strings.Unbounded But in this example I wanted to show the multiplier notation as well. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 22:13 ` conversion Robert I. Eachus @ 2003-06-30 8:52 ` Dmitry A. Kazakov 2003-07-03 7:03 ` conversion Robert I. Eachus 2003-07-05 2:40 ` conversion Alexander Kopilovitch 1 sibling, 1 reply; 44+ messages in thread From: Dmitry A. Kazakov @ 2003-06-30 8:52 UTC (permalink / raw) On Fri, 27 Jun 2003 22:13:54 GMT, "Robert I. Eachus" <rieachus@attbi.com> wrote: >Alexander Kopilovitch wrote: > >> The chorus also tells you that in Ada you should not need those conversion >> too often. Well, they are honest enough, they simply do not use Ada for >> a job and in an environment where you must mix varying strings and constant >> strings here and there, and at the same time you can't afford several weeks >> for design for every change in specifications. >> >> Ada simply understimates need of strings in non-numerical world (almost like >> Fortran IV, that is, before Fortran 77). I'm sure that Ada people would cry >> very loudly if there were similar situation with Integer type: imagine that >> there is unconstrained (for value, not for storage size) type Integer, which >> objects must be constrained (by value). Then, there are types Bounded_Integer >> and Unbounded_Integer. Unbounded_Integer is good for general use, except that >> you always have to write explicit conversion when you assign a literal (say, >> 1 or 0) to an object of Unbounded_Integer type (currently Ada Integer is like >> a Pascal string in this respect). > >This is silly. The situation in Ada is exactly the same with integer >and string types. If you mean that unversal integer is something like String, then you are probably right. But the difference is that we cannot declare objects of universal integer. On contrary, for strings we can, but surprisingly that type is called "Unbounded_String" and even more surprising is that it is unrelated to String. It is clear (isn't it) that all different string types have same semantics and differ only in how they implement that semantics. So they should be related. That length of a String value cannot be changed is just a value constraint which by no means changes string semantics. So instead of looking for explanations which I doubt would convince anybody, one could simply admit that, yes, String and Unbounded_String should be better siblings, but to do it consistently would require too many changes Ada's ADT model. For example, what would happen if type Name is new Unbounded_String; Should it produce a new String type? Surely. How should it be named? Who knows. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-30 8:52 ` conversion Dmitry A. Kazakov @ 2003-07-03 7:03 ` Robert I. Eachus 2003-07-09 7:42 ` conversion Dmitry A. Kazakov 0 siblings, 1 reply; 44+ messages in thread From: Robert I. Eachus @ 2003-07-03 7:03 UTC (permalink / raw) Dmitry A. Kazakov wrote: > If you mean that unversal integer is something like String, then you > are probably right. But the difference is that we cannot declare > objects of universal integer. On contrary, for strings we can, but > surprisingly that type is called "Unbounded_String" and even more > surprising is that it is unrelated to String. No! No! No! You are very confused. First of all, what do you think the type of Foo is in: Foo: constant := 123456789012; (Actually in Ada 95 it is _root_integer_ while the literal 123456789012 is of type _universal_integer_, but that is a detail. (_root_integer_ includes all other integer types, including _universal_integer_.) The Integer type that corresponds most closely to String, is Integer, and they are both declared in Standard. > It is clear (isn't it) that all different string types have same > semantics and differ only in how they implement that semantics. So > they should be related. Yes, so the three different implementations are all clustered under Ada.Strings: Ada.Strings.Fixed, Ada.Strings.Bounded, and Ada.Strings.Unbounded. > That length of a String value cannot be > changed is just a value constraint which by no means changes string > semantics. No. String values are never constrained, String objects are always constrained, often by their initial values. If I have a function that may return a different length string every time it is called, and that length is unpredictable in advance? That is not a problem, it is a common idiom: while not Done loop declare Buffer: String := Get_Line; begin -- process Buffer... end; end loop; There is no static/dynamic dichotomy here, nor is there a bounded/unbounded distinction, or even constrained/unconstrained. Buffer is always constrained to be the same length as the String returned by the most recent call to Get_Line. (Unfortunately that function is not Ada.Text_IO.Get_Line, but I hope we will fix that next time around.) > So instead of looking for explanations which I doubt would convince > anybody, one could simply admit that, yes, String and Unbounded_String > should be better siblings, but to do it consistently would require too > many changes Ada's ADT model. Ada.Strings.Fixed, Ada.Strings.Bounded, and Ada.Strings.Unbounded are the siblings. It may bother you that Ada.Strings.Fixed reuses String, and Ada.Strings.Bounded is a generic package you have to instantiate, but those are not the issues you are describing here. > For example, what would happen if > > type Name is new Unbounded_String; > > Should it produce a new String type? Surely. How should it be named? > Who knows. It would be named Name, unless I am missing something, just as: type New_String is new String; Creates a new string type named New_String. Or if you prefer: type New_String is array(Positive range <>) of Character; pragma Pack(String); Do that in Ada and you will find that you get a type with literals like "foo"... String is not a priviledged type in Ada. You can even create a new character type--Character is similarly not special. For example you could create a Cyrillic character type which used ISO 8859/5 Latin/Cyrillic with the upper and lower pages reversed. Or whatever. A character type is an enumeration type with character literals. A string type is any array of any character type. -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-03 7:03 ` conversion Robert I. Eachus @ 2003-07-09 7:42 ` Dmitry A. Kazakov 2003-07-09 17:04 ` conversion Robert I. Eachus 0 siblings, 1 reply; 44+ messages in thread From: Dmitry A. Kazakov @ 2003-07-09 7:42 UTC (permalink / raw) On Thu, 03 Jul 2003 07:03:43 GMT, "Robert I. Eachus" <rieachus@attbi.com> wrote: >Dmitry A. Kazakov wrote: > >> If you mean that unversal integer is something like String, then you >> are probably right. But the difference is that we cannot declare >> objects of universal integer. On contrary, for strings we can, but >> surprisingly that type is called "Unbounded_String" and even more >> surprising is that it is unrelated to String. > >No! No! No! You are very confused. First of all, what do you think the >type of Foo is in: > > Foo: constant := 123456789012; > >(Actually in Ada 95 it is _root_integer_ while the literal 123456789012 >is of type _universal_integer_, but that is a detail. (_root_integer_ >includes all other integer types, including _universal_integer_.) This is what I meant. You can consider string literals as being of some unversal string type. Then you can have some parent string type for all string types. Call it root string if you want. The hierarchy might look like: root string universal string = Unbounded_String String Bounded_String user-defined strings with literals user-defined strings with no literals >The Integer type that corresponds most closely to String, is Integer, >and they are both declared in Standard. It does not. Because Integer is constrained. >> It is clear (isn't it) that all different string types have same >> semantics and differ only in how they implement that semantics. So >> they should be related. > >Yes, so the three different implementations are all clustered under >Ada.Strings: Ada.Strings.Fixed, Ada.Strings.Bounded, and >Ada.Strings.Unbounded. This does not help. Types have to be related, order of packages is rather a cosmetic thing. > > That length of a String value cannot be > > changed is just a value constraint which by no means changes string > > semantics. > >No. String values are never constrained, String objects are always >constrained, often by their initial values. If I have a function that >may return a different length string every time it is called, and that >length is unpredictable in advance? That is not a problem, it is a >common idiom: > > while not Done loop > declare > Buffer: String := Get_Line; > begin > -- process Buffer... > end; > end loop; You missed the point. String as a concept has a semantics which allows *any* values. That String as a type implementing the concept has values constrained in some special way, does not change that semantics. >There is no static/dynamic dichotomy here, nor is there a >bounded/unbounded distinction, or even constrained/unconstrained. >Buffer is always constrained to be the same length as the String >returned by the most recent call to Get_Line. (Unfortunately that >function is not Ada.Text_IO.Get_Line, but I hope we will fix that next >time around.) Yes. >> So instead of looking for explanations which I doubt would convince >> anybody, one could simply admit that, yes, String and Unbounded_String >> should be better siblings, but to do it consistently would require too >> many changes Ada's ADT model. > >Ada.Strings.Fixed, Ada.Strings.Bounded, and Ada.Strings.Unbounded are >the siblings. >It may bother you that Ada.Strings.Fixed reuses String, >and Ada.Strings.Bounded is a generic package you have to instantiate, >but those are not the issues you are describing here. > >> For example, what would happen if >> >> type Name is new Unbounded_String; >> >> Should it produce a new String type? Surely. How should it be named? >> Who knows. > >It would be named Name, unless I am missing something, just as: > >type New_String is new String; > >Creates a new string type named New_String. Or if you prefer: > >type New_String is array(Positive range <>) of Character; >pragma Pack(String); > >Do that in Ada and you will find that you get a type with literals like >"foo"... String is not a priviledged type in Ada. You can even create >a new character type--Character is similarly not special. For example >you could create a Cyrillic character type which used ISO 8859/5 >Latin/Cyrillic with the upper and lower pages reversed. Or whatever. A >character type is an enumeration type with character literals. A string >type is any array of any character type. The problem is. Should String and Unbounded_String be siblings (descendants of same base), or better, as many would rightfully expect, String be *both* a subtype and a supertype of Unbounded_String, then we will have a lot of problems to solve. Because ADT in Ada is presently unable to deal with that. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-09 7:42 ` conversion Dmitry A. Kazakov @ 2003-07-09 17:04 ` Robert I. Eachus 2003-07-10 10:19 ` conversion Dmitry A. Kazakov 0 siblings, 1 reply; 44+ messages in thread From: Robert I. Eachus @ 2003-07-09 17:04 UTC (permalink / raw) Dmitry A. Kazakov wrote: > This is what I meant. You can consider string literals as being of > some unversal string type. Then you can have some parent string type > for all string types. Call it root string if you want. The hierarchy > might look like... This is where your confusion starts. String is the root type for all strings of Latin1 characters. If you want a universal type what it needs to cover are things like Wide_String, Wide_Wide_String, and any user defined string types with either a different set of characters, or different index types. Strings in Ada are much richer than your imagination realizes: type Color is (Red, Orange, Yellow, Green, Blue, Violet); type Digit is ('0','1','2','3','4','5','6','7','8','9'); type Digit_String is array (Color range <>) of Digit; -- new string type Foo: Digit_String := "12345"; >>The Integer type that corresponds most closely to String, is Integer, >>and they are both declared in Standard. > It does not. Because Integer is constrained. And String is constrained in exactly the same way. Most Ada implementations now have Integer'Last = 2**32-1, which not coincidentally is the maximum number of Characters in a String. > You missed the point. String as a concept has a semantics which allows > *any* values. That String as a type implementing the concept has > values constrained in some special way, does not change that > semantics. Hoo boy, you still are wearing blinders. In concept a string could be any ordered set of say Japanese Kanji, or if you prefer, and the Japanese do, a mixture of Katakana, Hirigana, and Kanji. In Ada this does't fit in a String, but Japanese is a subset of Wide_Character. And so Wide_String is fine for Japanese. On the other hand, Wide_Character cannot represent all of the Chinese characters, there are already several additional planes of additional Chinese characters defined in ISO 10646. In Ada the corresponding string type, if supported, would be Wide_Wide_Character. > The problem is. Should String and Unbounded_String be siblings > (descendants of same base), or better, as many would rightfully > expect, String be *both* a subtype and a supertype of > Unbounded_String, then we will have a lot of problems to solve. > Because ADT in Ada is presently unable to deal with that. But Unbounded_String is really a (very useful) container type for Standard.String, no more, no less. I can easily imagine--because I have had to do it in Ada 83 which was not as friendly in this area--writing a package which had to display messages in Latin (English), Cyrillic, and Arabic. Three separate (7-bit) character sets, and the corresponding string types. If I were to rewrite that code in Ada 95, I would probably use the corresponding ISO 8859 8-bit character sets. But I would need an instance of Ada.Strings.Bounded_String for each. (Well actually only the Latin1 version could be an instance of Ada.Strings.Bounded_String, but that is a detail.) Why am I spending so much time on this? Simple. A lot of effort over the years has gone into the support for additional character sets (and string types) in Ada. The most recent discussion was whether or not to "officially" change the default character set to one of the new 8859 variants with the Euro symbol. (Verdict, no.) People who look at Ada through a mono-linguistic filter tend to miss this. But what really suprises me is the fact that many people whose first language is not English still tend to think of Ada as having an English bias. (Technically, Ada does have a slight Western European bias, but very slight, see 3.5.2.(4). And as I indicated above Ada does not define the Wide_Wide_Character type needed for full Chinese language support.) -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-09 17:04 ` conversion Robert I. Eachus @ 2003-07-10 10:19 ` Dmitry A. Kazakov 2003-07-11 1:56 ` conversion Alexander Kopilovitch 0 siblings, 1 reply; 44+ messages in thread From: Dmitry A. Kazakov @ 2003-07-10 10:19 UTC (permalink / raw) On Wed, 09 Jul 2003 17:04:53 GMT, "Robert I. Eachus" <rieachus@attbi.com> wrote: >Dmitry A. Kazakov wrote: > >> This is what I meant. You can consider string literals as being of >> some unversal string type. Then you can have some parent string type >> for all string types. Call it root string if you want. The hierarchy >> might look like... > >This is where your confusion starts. String is the root type for all >strings of Latin1 characters. If you want a universal type what it >needs to cover are things like Wide_String, Wide_Wide_String, and any >user defined string types with either a different set of characters, or >different index types. Strings in Ada are much richer than your >imagination realizes: Your example proves exactly the opposite. How to get an Unbounded_String of Colors? >type Color is (Red, Orange, Yellow, Green, Blue, Violet); > >type Digit is ('0','1','2','3','4','5','6','7','8','9'); > >type Digit_String is array (Color range <>) of Digit; -- new string type > >Foo: Digit_String := "12345"; Yes, and why is this? Because Ada 83 did it (arrays) in a right, though a very limited way. On the contrary, Ada 95 failed to extend ADT in a reasonable way. So we have got a private Unbounded_String falling out of the concept. >>>The Integer type that corresponds most closely to String, is Integer, >>>and they are both declared in Standard. > >> It does not. Because Integer is constrained. > >And String is constrained in exactly the same way. Most Ada >implementations now have Integer'Last = 2**32-1, which not >coincidentally is the maximum number of Characters in a String. Compare: X : Integer := 5; Y : String := "12345"; begin X := 7; Y := "1234567"; A decalration of a string variable, in effect, also declares an anonymous constrained subtype which makes the last assignment illegal. It is not so for integer types. >> You missed the point. String as a concept has a semantics which allows >> *any* values. That String as a type implementing the concept has >> values constrained in some special way, does not change that >> semantics. > >Hoo boy, you still are wearing blinders. In concept a string could be >any ordered set of say Japanese Kanji, or if you prefer, and the >Japanese do, a mixture of Katakana, Hirigana, and Kanji. Absolutely! >In Ada this >does't fit in a String, but Japanese is a subset of Wide_Character. And > so Wide_String is fine for Japanese. On the other hand, Wide_Character >cannot represent all of the Chinese characters, there are already >several additional planes of additional Chinese characters defined in >ISO 10646. In Ada the corresponding string type, if supported, would be >Wide_Wide_Character. It is not a problem if you have a full blown ADT. If we could say that one array is a subtype of another, then all problems would disappear. The type of elements will become a representation issue. So even Wide_Wide_Very_Wide_Unbounded_Remote_Oracle_String could be yet made a sub- and supertype of String, i.e. substitutable. >> The problem is. Should String and Unbounded_String be siblings >> (descendants of same base), or better, as many would rightfully >> expect, String be *both* a subtype and a supertype of >> Unbounded_String, then we will have a lot of problems to solve. >> Because ADT in Ada is presently unable to deal with that. > >But Unbounded_String is really a (very useful) container type for >Standard.String, no more, no less. Yes, it does not solve the problem, so people are unhappy with it. What I am trying to say is that to get it right would require too many changes in Ada, which was impossible then and, I am afraid, is still impossible now. >I can easily imagine--because I have >had to do it in Ada 83 which was not as friendly in this area--writing a >package which had to display messages in Latin (English), Cyrillic, and >Arabic. Three separate (7-bit) character sets, and the corresponding >string types. If I were to rewrite that code in Ada 95, I would >probably use the corresponding ISO 8859 8-bit character sets. But I >would need an instance of Ada.Strings.Bounded_String for each. (Well >actually only the Latin1 version could be an instance of >Ada.Strings.Bounded_String, but that is a detail.) > >Why am I spending so much time on this? Simple. A lot of effort over >the years has gone into the support for additional character sets (and >string types) in Ada. The most recent discussion was whether or not to >"officially" change the default character set to one of the new 8859 >variants with the Euro symbol. (Verdict, no.) People who look at Ada >through a mono-linguistic filter tend to miss this. But what really >suprises me is the fact that many people whose first language is not >English still tend to think of Ada as having an English bias. (:-)) I would recommend you to take a look at Russian edition of revised report on ALGOL 68, with Cyrillic identifiers and keywords. Even a native Russian is unable to understand such a garbage. >(Technically, Ada does have a slight Western European bias, but very >slight, see 3.5.2.(4). And as I indicated above Ada does not define the >Wide_Wide_Character type needed for full Chinese language support.) And it also should not. ADT can deal with all that on the basis of user-defined types. You cannot support all possible languages. It is utopic. Alone Russian has dozens of different code tables. Germans are going to eliminate their beta (�). Would change the language standard each time some of 200 crazy governments over the world modify an alphabet? --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-10 10:19 ` conversion Dmitry A. Kazakov @ 2003-07-11 1:56 ` Alexander Kopilovitch 0 siblings, 0 replies; 44+ messages in thread From: Alexander Kopilovitch @ 2003-07-11 1:56 UTC (permalink / raw) Dmitry A. Kazakov wrote: >(:-)) I would recommend you to take a look at Russian edition of >revised report on ALGOL 68, with Cyrillic identifiers and keywords. >Even a native Russian is unable to understand such a garbage. Oh, yes. Those "Russian keywords" were great -;) . If I remember right, "file" became "fund" (that is, if we translate that Russian keyword for "file" into English we'll get "fund" or "foundation"). But generally (not for Algol 68 only, but everywhere) it always was the common way to understand "russified" programming term: just guess how it was called in English. >... Alone Russian has dozens of different code tables. You exaggregate, I think - I believe that there are no more than 8-10 Cyrillic code tables in current use -;) . There is surely no more than 4 Cyrillic code tables for PC (including Windows, DOS, OS/2, Linux and various flavours of Unix), other non-Russian computers (except IBM mainframes) add none. (Don't forget that most of hardware/software "legacy" in Russia was completely and irreversibly disappeared over past 15 years.) Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-06-27 22:13 ` conversion Robert I. Eachus 2003-06-30 8:52 ` conversion Dmitry A. Kazakov @ 2003-07-05 2:40 ` Alexander Kopilovitch 2003-07-05 6:33 ` conversion Georg Bauhaus 1 sibling, 1 reply; 44+ messages in thread From: Alexander Kopilovitch @ 2003-07-05 2:40 UTC (permalink / raw) Robert I. Eachus wrote: >... The situation in Ada is exactly the same with integer >and string types. But the situation in applications is not the same. >... The Ada.Strings.Bounded and Ada.Strings.Unbounded packages provide a way to >create objects that have only a maximum or no minimum and no maximum >length respectively. The equivalent for integer types is a bignum >package, which supports any size integer value without Constraint_Error. So, Unbounded_String corresponds to bignum. Good, I may even like this analogy. But imagine that Ada language once becomes somehow more popular (well, not so popular as Visual Basic or even C++ -:) . How many programmers will need bignum package? Very tiny fraction (and I think that even now the same is true). But most of programmers that use (even moderately) widespread language will need Unbounded_String. The varying strings of unspecified maximum size are common for many applications outside of current, quite restricted Ada world. And arrays of such strings are no less common. And I'm sure that at least initialization with literals must be provided directly, without any explicit conversions. I can imagine that most often there are ways (of which I'm not aware) to avoid heavy use of Unbounded_Strings. If this is true then I wish this ways be explained -- for programmer, not for language lawyer - in some book (or at least in comprehensive article) dedicated to this issue. Dmitry A. Kazakov wrote: >So instead of looking for explanations which I doubt would convince >anybody, one could simply admit that, yes, String and Unbounded_String >should be better siblings, but to do it consistently would require too >many changes Ada's ADT model. I tried (about year ago, I think) to propose (in Ada-Comment) a construct for this purpose: type Y is private envelope of X; which should lead to type Unbounded_String is private envelope of String; This my proposition did not sink in silence, I was faced with a list of remarks and questions... I tried to respond for them, but failed miserably, due to lack of language lawyer skills and experience. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-05 2:40 ` conversion Alexander Kopilovitch @ 2003-07-05 6:33 ` Georg Bauhaus 2003-07-05 17:06 ` conversion Alexander Kopilovitch 0 siblings, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2003-07-05 6:33 UTC (permalink / raw) Alexander Kopilovitch <aek@vib.usr.pu.ru> wrote: : The varying strings of unspecified maximum size are common for many applications : outside of current, quite restricted Ada world. And arrays of such strings : are no less common. Care to list some examples? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-05 6:33 ` conversion Georg Bauhaus @ 2003-07-05 17:06 ` Alexander Kopilovitch 2003-07-06 3:53 ` conversion Robert I. Eachus 2003-07-06 20:04 ` conversion Georg Bauhaus 0 siblings, 2 replies; 44+ messages in thread From: Alexander Kopilovitch @ 2003-07-05 17:06 UTC (permalink / raw) Georg Bauhaus wrote: > > The varying strings of unspecified maximum size are common for many applications > > outside of current, quite restricted Ada world. And arrays of such strings > > are no less common. > >Care to list some examples? /* C/C++ example */ char *Titles[] = { "Quizionary", "Nose To Nose", "Myself", "General Dissent", "Veteran's Opinion", "Corporate Science Weekly", "Truth, Wealth, Health", "Bribery Times" }; { Object Pascal example } const Dishes : array [1..4] of String = ( 'black pudding', 'crab soup', 'steak & kidney pie', 'lemon tart' ); Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-05 17:06 ` conversion Alexander Kopilovitch @ 2003-07-06 3:53 ` Robert I. Eachus 2003-07-06 5:13 ` conversion Jeffrey Carter 2003-07-07 1:09 ` conversion Alexander Kopilovitch 2003-07-06 20:04 ` conversion Georg Bauhaus 1 sibling, 2 replies; 44+ messages in thread From: Robert I. Eachus @ 2003-07-06 3:53 UTC (permalink / raw) Alexander Kopilovitch wrote: > /* C/C++ example */ > > char *Titles[] = { > "Quizionary", > "Nose To Nose", > "Myself", > "General Dissent", > "Veteran's Opinion", > "Corporate Science Weekly", > "Truth, Wealth, Health", > "Bribery Times" > }; > > > { Object Pascal example } > > const > Dishes : array [1..4] of String = ( > 'black pudding', > 'crab soup', > 'steak & kidney pie', > 'lemon tart' > ); Two examples. One without any Ada support packages, and one that uses Ada.Strings.Bounded. Personally I think that during standarization, to much was added in, and as a result, Ada.Strings.Bounded is harder to use than it should be. But of course, you can roll your own, the way you had to in Ada 83. But notice two major differences between the Ada way, and the C and Pascal way. The Ada solutions are built around standard Ada features, not special case features, and the Ada solution allows for non-constant arrays, in fact the individual elements can change in length. (Yes, I know that in the C++ case you can assign other pointers, but the original values can't be modified as such.) procedure Varying is -- an example of how to create ragged arrays in Ada. subtype Lim_Int is Integer range 0..30; type Inner(L: Lim_Int := 0) is record S: String(1..L); end record; type Wrapper is record I: Inner; end record; type Ragged_Array is array (Integer range <>) of Wrapper; function "+" (S: in String) return Wrapper is begin return (I =>(S'Length, S)); end "+"; function "+" (W: in Wrapper) return String is begin return W.I.S; end "+"; Dishes: Ragged_Array := (+"black pudding", +"crab soup", +"steak & kidney pie", +"lemon tart"); Titles: Ragged_Array := (+"Quizionary", +"Nose To Nose", +"Myself", +"General Dissent", +"Veteran's Opinion", +"Corporate Science Weekly", +"Truth, Wealth, Health", +"Bribery Times"); begin null; end Varying; with Ada.Strings.Bounded; procedure Varying2 is -- an example of how to use Ada.Strings.Bounded. package Bounded_Str is new Ada.Strings.Bounded.Generic_Bounded_Length(30); subtype Bounded_String is Bounded_Str.Bounded_String; function "+" (S: in String) return Bounded_String is begin return Bounded_Str.To_Bounded_String(S, Ada.Strings.Error); end "+"; function "+" (B: in Bounded_String) return String renames Bounded_Str.To_String; type Ragged_Array is array (Integer range <>) of Bounded_String; Dishes: Ragged_Array := (+"black pudding", +"crab soup", +"steak & kidney pie", +"lemon tart"); Titles: Ragged_Array := (+"Quizionary", +"Nose To Nose", +"Myself", +"General Dissent", +"Veteran's Opinion", +"Corporate Science Weekly", +"Truth, Wealth, Health", +"Bribery Times"); begin null; end Varying2; -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-06 3:53 ` conversion Robert I. Eachus @ 2003-07-06 5:13 ` Jeffrey Carter 2003-07-06 12:45 ` conversion Chad R. Meiners 2003-07-07 1:09 ` conversion Alexander Kopilovitch 1 sibling, 1 reply; 44+ messages in thread From: Jeffrey Carter @ 2003-07-06 5:13 UTC (permalink / raw) Robert I. Eachus wrote: > > Dishes: Ragged_Array := (+"black pudding", > +"crab soup", > +"steak & kidney pie", > +"lemon tart"); I think we should allow the unary function "\" for this kind of thing, so we can drive C people crazy by writing Dishes : Ragged_Array := (\"black pudding", \"crab soup", \"steak & kidney pie", \"lemon tart"); -- Jeff Carter "This trial is a travesty. It's a travesty of a mockery of a sham of a mockery of a travesty of two mockeries of a sham. ... Do you realize there's not a single homosexual on that jury?" Bananas ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-06 5:13 ` conversion Jeffrey Carter @ 2003-07-06 12:45 ` Chad R. Meiners 0 siblings, 0 replies; 44+ messages in thread From: Chad R. Meiners @ 2003-07-06 12:45 UTC (permalink / raw) "Jeffrey Carter" <spam@spam.com> wrote in message news:3F07B075.8020807@spam.com... > I think we should allow the unary function "\" for this kind of thing, > so we can drive C people crazy by writing Nice, but what we really need is the new unary "" function for this kind of thing ;-) You would just have to be careful where you make it visible ;-) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-06 3:53 ` conversion Robert I. Eachus 2003-07-06 5:13 ` conversion Jeffrey Carter @ 2003-07-07 1:09 ` Alexander Kopilovitch 1 sibling, 0 replies; 44+ messages in thread From: Alexander Kopilovitch @ 2003-07-07 1:09 UTC (permalink / raw) Robert I. Eachus wrote: >But notice two major differences between the Ada way, and the C and >Pascal way. The Ada solutions are built around standard Ada features, >not special case features, I do not see major difference between C and Ada general approaches to strings (Pascal is another matter). In both C and Ada strings are no more than regular arrays of characters - in core language, and all support for them is in standard library only. The particular difference between C and Ada regarding literals in a string array initializer is then simply a consequence of C's array/pointer kinship. >procedure Varying is -- an example of how to create ragged arrays in Ada. > > subtype Lim_Int is Integer range 0..30; > type Inner(L: Lim_Int := 0) is record S: String(1..L); end record; > type Wrapper is record I: Inner; end record; > type Ragged_Array is array (Integer range <>) of Wrapper; > > function "+" (S: in String) return Wrapper is > begin return (I =>(S'Length, S)); end "+"; > > function "+" (W: in Wrapper) return String is > begin return W.I.S; end "+"; Just interesting detail: you use the same name "+" for both conversions. (I do not argue against that, I simply found that somehow symptomatic.) > Dishes: Ragged_Array := (+"black pudding", > +"crab soup", > +"steak & kidney pie", > +"lemon tart"); > > Titles: Ragged_Array := (+"Quizionary", > +"Nose To Nose", > +"Myself", > +"General Dissent", > +"Veteran's Opinion", > +"Corporate Science Weekly", > +"Truth, Wealth, Health", > +"Bribery Times"); > >begin null; end Varying; As you may expect, I'm not satisfied with two things here: 1) Lim_Int - why 30, why not 123 ? Why should I always bother myself with justification of this value, and then, at the end, sooner or later, invite something like Ariane 5 effect (hopefully, in much lesser scale -;) ? 2) "+" at the beginning of each string literal. It reads as "Warning! This programming language does not pay particular attention to strings, you will be often obliged to do manually some common things with the strings". First point is certainly minor, because I can use Unbounded_String here. But the second point is quite significant. Just compare the situation with richness of representations for literals for numeric types in Ada. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-05 17:06 ` conversion Alexander Kopilovitch 2003-07-06 3:53 ` conversion Robert I. Eachus @ 2003-07-06 20:04 ` Georg Bauhaus 2003-07-07 14:55 ` conversion Stephen Leake 1 sibling, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2003-07-06 20:04 UTC (permalink / raw) Alexander Kopilovitch <aek@vib.usr.pu.ru> wrote: : Georg Bauhaus wrote: : :> > The varying strings of unspecified maximum size are common for many applications :> > outside of current, quite restricted Ada world. And arrays of such strings :> > are no less common. :> :>Care to list some examples? : : /* C/C++ example */ : : char *Titles[] = { : "Quizionary", : "Nose To Nose", : "Myself", : "General Dissent", : "Veteran's Opinion", : "Corporate Science Weekly", : "Truth, Wealth, Health", : "Bribery Times" : }; If you need to have syntactic sugar, you can have Titles: constant array(1..8) of String_Access := (-"Quizionary", -"Nose To Nose", -"Myself", -"General Dissent", -"Veteran's Opinion", -"Corporate Science Weekly", -"Truth, Wealth, Health", -"Bribery Times"); where function "-"(s: String) return String_Access; I am always trying something like the following. The string literals end up as literals in the assembly listing, so there does not seem to be allocation at run time, despite new: procedure str is type String_Access is access constant String; Titles: constant array(1..8) of String_Access := (new String'("Quizionary"), new String'("Nose To Nose"), new String'("Myself"), new String'("General Dissent"), new String'("Veteran's Opinion"), new String'("Corporate Science Weekly"), new String'("Truth, Wealth, Health"), new String'("Bribery Times")); begin null; end str; But, as a sidenote, I alway try to avoid string literals in source code. They make the text fixed, a typo requires recompilation, language translation requires that programmers be involved, because the translators do not know how to recompile the program to include the latest translations, etc. If that seems too much, there could be an enumeration of the 8 strings above, such that, for every natural language (or other variation in the string values), you could have array(Languages, Kinds_of_Titles) of String_Access := ...; in some library package. What is more, the varying size you have mentioned is known at compile time in your example. But for sure string literals are not the usual input to a string processing program? -- Georg ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-06 20:04 ` conversion Georg Bauhaus @ 2003-07-07 14:55 ` Stephen Leake 2003-07-07 21:36 ` conversion Alexander Kopilovitch 0 siblings, 1 reply; 44+ messages in thread From: Stephen Leake @ 2003-07-07 14:55 UTC (permalink / raw) > Alexander Kopilovitch <aek@vib.usr.pu.ru> wrote: > : Georg Bauhaus wrote: > : > :> > The varying strings of unspecified maximum size are common for > :> > many applications outside of current, quite restricted Ada > :> > world. And arrays of such strings are no less common. > :> > :>Care to list some examples? > : > : /* C/C++ example */ > : > : char *Titles[] = { > : "Quizionary", > : "Nose To Nose", > : "Myself", > : "General Dissent", > : "Veteran's Opinion", > : "Corporate Science Weekly", > : "Truth, Wealth, Health", > : "Bribery Times" > : }; These are _not_ "varying strings of unspecified length"! These are all _constant_ strings, whose length is determined from the initializer. The compiler should put them in the "constant" section, so you can't even treat them as ordinary C null-terminated variable strings; you can't write to them! -- -- Stephe ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 2003-07-07 14:55 ` conversion Stephen Leake @ 2003-07-07 21:36 ` Alexander Kopilovitch 0 siblings, 0 replies; 44+ messages in thread From: Alexander Kopilovitch @ 2003-07-07 21:36 UTC (permalink / raw) Stephen Leake wrote: >> :> > The varying strings of unspecified maximum size are common for >> :> > many applications outside of current, quite restricted Ada >> :> > world. And arrays of such strings are no less common. >> :> >> :>Care to list some examples? >> : >> : /* C/C++ example */ >> : >> : char *Titles[] = { >> : "Quizionary", >> : "Nose To Nose", >> : "Myself", >> : "General Dissent", >> : "Veteran's Opinion", >> : "Corporate Science Weekly", >> : "Truth, Wealth, Health", >> : "Bribery Times" >> : }; > >These are _not_ "varying strings of unspecified length"! > >These are all _constant_ strings, whose length is determined from the >initializer. The compiler should put them in the "constant" section, >so you can't even treat them as ordinary C null-terminated variable >strings; you can't write to them! "varying" always is relative to some account of time, right? Well, I meant more "lifetime" than "run-time" of a program. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 44+ messages in thread
* conversion @ 1998-07-22 0:00 Rick 1998-07-22 0:00 ` conversion Richard Toy 1998-07-22 0:00 ` conversion Corey Ashford 0 siblings, 2 replies; 44+ messages in thread From: Rick @ 1998-07-22 0:00 UTC (permalink / raw) how do you convert a string into an integer? thanks ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 1998-07-22 0:00 conversion Rick @ 1998-07-22 0:00 ` Richard Toy 1998-07-22 0:00 ` conversion Corey Ashford 1 sibling, 0 replies; 44+ messages in thread From: Richard Toy @ 1998-07-22 0:00 UTC (permalink / raw) To: Rick Rick wrote: > > how do you convert a string into an integer? > thanks Try looking at 'Value or an instanciation of Integer_Io and "procedure Get (From : in String; Item : out Num; Last : out Positive)" in the LRM. -- Regards Richard Toy ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 1998-07-22 0:00 conversion Rick 1998-07-22 0:00 ` conversion Richard Toy @ 1998-07-22 0:00 ` Corey Ashford 1998-07-22 0:00 ` conversion Corey Ashford 1 sibling, 1 reply; 44+ messages in thread From: Corey Ashford @ 1998-07-22 0:00 UTC (permalink / raw) Rick wrote in message <35B628C1.F358EAEE@world-net.net>... >how do you convert a string into an integer? >thanks > the easiest way is to use the 'value attribute. declare ... foo : constant string := integer'value(some_integer_variable); ... begin ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: conversion 1998-07-22 0:00 ` conversion Corey Ashford @ 1998-07-22 0:00 ` Corey Ashford 0 siblings, 0 replies; 44+ messages in thread From: Corey Ashford @ 1998-07-22 0:00 UTC (permalink / raw) Corey Ashford wrote in message <6p5qq9$ifd$1@usenet.rational.com>... > >Rick wrote in message <35B628C1.F358EAEE@world-net.net>... >>how do you convert a string into an integer? >>thanks >> > >the easiest way is to use the 'value attribute. > >declare >... > foo : constant string := integer'value(some_integer_variable); >... >begin > > > oops... I reversed that foo : integer := integer'value(some_string_value); ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2003-07-11 1:56 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-28 8:46 conversion Andrew 2003-06-28 9:49 ` conversion Preben Randhol 2003-06-30 14:08 ` conversion Stephen Leake [not found] <002701c33e22$8e9deaf0$0201a8c0@win> 2003-06-29 20:15 ` conversion David C. Hoos, Sr. -- strict thread matches above, loose matches on Subject: below -- 2003-06-29 9:41 conversion Andrew 2003-07-04 10:42 ` conversion Janeit 2003-06-27 17:37 conversion Andrew 2003-06-27 17:32 ` conversion Stephen Leake 2003-06-28 2:55 ` conversion Jeffrey Carter 2003-06-27 10:51 conversion Andrew 2003-06-27 12:22 ` conversion Dmitry A. Kazakov 2003-06-27 12:37 ` conversion Stephen Leake 2003-06-27 14:26 ` conversion Bill Findlay 2003-06-27 17:04 ` conversion Georg Bauhaus 2003-07-04 0:21 ` conversion Dave Thompson 2003-06-27 13:25 ` conversion Robert I. Eachus 2003-06-27 18:42 ` conversion tmoran 2003-06-27 14:49 ` conversion Matthew Heaney 2003-06-27 17:10 ` conversion Georg Bauhaus 2003-06-27 17:13 ` conversion Alexander Kopilovitch 2003-06-27 17:34 ` conversion Preben Randhol 2003-06-27 22:10 ` conversion Alexander Kopilovitch 2003-06-28 9:46 ` conversion Preben Randhol 2003-06-27 22:13 ` conversion Robert I. Eachus 2003-06-30 8:52 ` conversion Dmitry A. Kazakov 2003-07-03 7:03 ` conversion Robert I. Eachus 2003-07-09 7:42 ` conversion Dmitry A. Kazakov 2003-07-09 17:04 ` conversion Robert I. Eachus 2003-07-10 10:19 ` conversion Dmitry A. Kazakov 2003-07-11 1:56 ` conversion Alexander Kopilovitch 2003-07-05 2:40 ` conversion Alexander Kopilovitch 2003-07-05 6:33 ` conversion Georg Bauhaus 2003-07-05 17:06 ` conversion Alexander Kopilovitch 2003-07-06 3:53 ` conversion Robert I. Eachus 2003-07-06 5:13 ` conversion Jeffrey Carter 2003-07-06 12:45 ` conversion Chad R. Meiners 2003-07-07 1:09 ` conversion Alexander Kopilovitch 2003-07-06 20:04 ` conversion Georg Bauhaus 2003-07-07 14:55 ` conversion Stephen Leake 2003-07-07 21:36 ` conversion Alexander Kopilovitch 1998-07-22 0:00 conversion Rick 1998-07-22 0:00 ` conversion Richard Toy 1998-07-22 0:00 ` conversion Corey Ashford 1998-07-22 0:00 ` conversion Corey Ashford
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox