* functions, packages & characters @ 2002-02-21 0:16 Unversed Angel 2002-02-21 0:37 ` tmoran 0 siblings, 1 reply; 42+ messages in thread From: Unversed Angel @ 2002-02-21 0:16 UTC (permalink / raw) Hi, i am new to programming and am learning Ada. I have been staring at the screen all day and don't know what to do. I want to know if you can put a couple of functions through a procedure because my compiler keeps stopping me, should i be using packages and how would i do that? Also i need to replace a // with one / in my program and can't find anything similar in any books. Any help would be useful. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 0:16 functions, packages & characters Unversed Angel @ 2002-02-21 0:37 ` tmoran 2002-02-21 1:13 ` Unversed Angel 0 siblings, 1 reply; 42+ messages in thread From: tmoran @ 2002-02-21 0:37 UTC (permalink / raw) > I want to know if you can put a couple of functions through a procedure What do you mean by "put a function through a procedure"? > my compiler keeps stopping me, The compiler is not trying to be difficult, it just doesn't understand either. > Also i need to replace a // with one / in my program Surely your editor/word processor has a "replace" capability. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 0:37 ` tmoran @ 2002-02-21 1:13 ` Unversed Angel 2002-02-21 2:53 ` tmoran 0 siblings, 1 reply; 42+ messages in thread From: Unversed Angel @ 2002-02-21 1:13 UTC (permalink / raw) I want to know if i can include several functions in one main program. I don't know how to find/use the "replace" capability and so far i have this but since i've been at the screen all day i don't know if it's gibberish or not. with Text_IO; use Text_IO; procedure Simple1 is --- ---pre: tags are in the text ---post:tags have been correctly reformatted --- Text: File; begin Put_Line ("Please enter text: "); function Get_Line (Text :String) return Unbounded_String; begin Get_Line; end; function Find_Dblslash (//) return Single Slash(/); begin if any c=// then use function Find_dblslash; end if; end; end; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 1:13 ` Unversed Angel @ 2002-02-21 2:53 ` tmoran 2002-02-21 8:25 ` Unversed Angel 0 siblings, 1 reply; 42+ messages in thread From: tmoran @ 2002-02-21 2:53 UTC (permalink / raw) > I want to know if i can include several functions in one main program. Yes, you can declare functions in the declarative part of another function (or procedure or block). So you could modify your program to declare your function Get_Line just after "Text: File;" for instance. Of course you would have to give an executable body for the function too, or perhaps in this case you just want it to rename the standard To_Unbounded_String function. Similarly you could declare a function Find_Dblslash, including coding what it does. Take a look at your Ada texts/tutorials to see examples. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 2:53 ` tmoran @ 2002-02-21 8:25 ` Unversed Angel 2002-02-21 13:47 ` Marin David Condic 2002-02-22 0:22 ` tmoran 0 siblings, 2 replies; 42+ messages in thread From: Unversed Angel @ 2002-02-21 8:25 UTC (permalink / raw) I have been looking at my program and wondered if this woul work package obtain is function Get_Line; end obtain; with Text_io; use Text_io; package body obtain is begin function Get_Line (Text :String) return Unbounded_String; Get_Line; end; With Text_IO; use Text_IO; with obtain procedure main is --- ---pre: tags are in the text ---post:tags have been correctly reformatted --- Text: File; function Find_Dblslash (//) return Single Slash(/)procedure main is begin Put_Line ("Please enter text: "); use obtain; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 8:25 ` Unversed Angel @ 2002-02-21 13:47 ` Marin David Condic 2002-02-22 0:22 ` tmoran 1 sibling, 0 replies; 42+ messages in thread From: Marin David Condic @ 2002-02-21 13:47 UTC (permalink / raw) It appears that you really need to get a bit more formal training regarding the structure of Ada programs. A good place to start would be to go to: http://www.adapower.com/ and look under "Books" and "Learn Ada" (The latter will point you at on line tutorials and books so you don't even have to spend money or wait for something to come in from the bookstore.) Try working through one of these books and their examples, because it will clear up the fundamental misunderstandings you have about how to structure the code. From there we can be a *lot* more helpful with specific questions about individual features of the language. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Unversed Angel" <unversedangel@aol.com> wrote in message news:20020221032525.25608.00002542@mb-mc.aol.com... > I have been looking at my program and wondered if this woul work > > package obtain is > function Get_Line; > end obtain; > > with Text_io; > use Text_io; > package body obtain is > begin > function Get_Line (Text :String) > return Unbounded_String; > Get_Line; > end; > > With Text_IO; > use Text_IO; > with obtain > procedure main is > --- > ---pre: tags are in the text > ---post:tags have been correctly reformatted > --- > Text: File; > > function Find_Dblslash (//) > return Single Slash(/)procedure main is > begin > Put_Line ("Please enter text: "); > use obtain; > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 8:25 ` Unversed Angel 2002-02-21 13:47 ` Marin David Condic @ 2002-02-22 0:22 ` tmoran 1 sibling, 0 replies; 42+ messages in thread From: tmoran @ 2002-02-22 0:22 UTC (permalink / raw) > package obtain is > function Get_Line; > end obtain; > > with Text_io; > use Text_io; > package body obtain is > begin <- oops You are making progress toward a syntactically legal Ada program. But you don't write a novel by starting with a bunch of sentence fragments and trying to rearrange them until a Publisher says "Yes!". First you learn how to compose legal, meaningful, sentences. Then you decide on a structure and plot for your novel, and finally you write sentences to show the reader the story. It appears you really need an Ada textbook, either paper or online. Or at the very least, study some existing Ada programs and copy and modify to get one to do what you want. Look at www.adapower.com for references to books, tutorials, and sample source code. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters @ 2002-02-21 8:59 Christoph Grein 2002-02-21 18:07 ` Unversed Angel 0 siblings, 1 reply; 42+ messages in thread From: Christoph Grein @ 2002-02-21 8:59 UTC (permalink / raw) From the code you provided we can see that you are completely unfamiliar with Ada, this will never compile. This is not an accusation, we all have been beginners some time :-) but please take an intoductory book about Ada (see AdaPower) and work thru it. There are so many problems in the code it's really no use to correct them all. You really have to get a basic understanding of Ada first. Begin with a hello world program: with Ada.Text_IO; procedure Hello is procedure Say_Hello is begin Ada.Text_IO.Put_Line ("Hello Greenhorn :-)"); end Say_Hello; begin Say_Hello; end Hello; > I have been looking at my program and wondered if this woul work > > package obtain is > function Get_Line; <--- return type missing > end obtain; > > with Text_io; > use Text_io; > package body obtain is > begin <--- remove this line (wrong here) > function Get_Line (Text :String) <--- body does not match specification > return Unbounded_String; <--- replace ; by is begin > Get_Line; <--- Parameters missing <--- return stement missing > end; <--- another end statement missing etc.... > > With Text_IO; > use Text_IO; > with obtain > procedure main is > --- > ---pre: tags are in the text > ---post:tags have been correctly reformatted > --- > Text: File; > > function Find_Dblslash (//) > return Single Slash(/)procedure main is > begin > Put_Line ("Please enter text: "); > use obtain; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 8:59 Christoph Grein @ 2002-02-21 18:07 ` Unversed Angel 2002-02-21 18:28 ` Hyman Rosen 2002-02-21 22:48 ` unversedangel 0 siblings, 2 replies; 42+ messages in thread From: Unversed Angel @ 2002-02-21 18:07 UTC (permalink / raw) >From the code you provided we can see that you are completely unfamiliar with > >Ada, this will never compile. > Yes i am new to Ada but the problem with the other program was that i'd been staring at the screen too long. This program is more similar with what i need to do next but i have no idea if its any good. Any help would be appreciated. with Text_io; use Text_io; procedure main is ---pre: text is in the mark up language ---post: text has been converted to english ---test: once thru t:string procedure Get_line is ---pre:text needs to be input Line_Buffer : String (1 .. 1000); Line_Length : Natural range 0 .. Line_Buffer'Last; Line_Store : array (1 .. 10_000) of Unbounded_String; Line_Count : Natural range 0 .. Line_Store'Last; begin loop Get_Line (Line_Buffer, Line_Length); Line_Count := Line_Count + 1; Line_Store (Line_Count) := To_Unbounded_String (Line_Buffer (1 .. Line_Length)); new_line; end loop; end; Procedure doubleslash is ---pre:mark up language has been input ---post:doubleslash has been converted to single slash ---test: /,//,/// begin Loop For i in t'range loop if t(i)=// then t:=/; end if; end loop; end; procedure /N is pre: ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 18:07 ` Unversed Angel @ 2002-02-21 18:28 ` Hyman Rosen 2002-02-21 23:44 ` Randy Brukardt 2002-02-21 23:49 ` unversedangel 2002-02-21 22:48 ` unversedangel 1 sibling, 2 replies; 42+ messages in thread From: Hyman Rosen @ 2002-02-21 18:28 UTC (permalink / raw) Unversed Angel wrote: > Line_Buffer : String (1 .. 1000); It's the twenty-first century. Isn't it about time we got rid of fixed-size input buffers? Thank goodness for the GNU reimplementation of the UNIX utilities, which have done away with maximum line sizes, but on my Sun, I still can't vi in a 200 column xterm. Unless you have very domain-specific information, using a fixed-size input buffer is an invitation to errors. You will never pick a large-enough size. I once had to process a .newsrc file, which is plain text, whose longest line was several hundred thousand characters long. The most pernicious error in such a case is for the program to silently truncate the line, or to split it into multiple lines. Using unbounded input buffers prevents this from happening. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 18:28 ` Hyman Rosen @ 2002-02-21 23:44 ` Randy Brukardt 2002-02-22 0:37 ` Matthew Heaney ` (3 more replies) 2002-02-21 23:49 ` unversedangel 1 sibling, 4 replies; 42+ messages in thread From: Randy Brukardt @ 2002-02-21 23:44 UTC (permalink / raw) Hyman Rosen wrote in message <3C753C66.8020509@mail.com>... >Unversed Angel wrote: >> Line_Buffer : String (1 .. 1000); > >It's the twenty-first century. Isn't it about time we >got rid of fixed-size input buffers? Thank goodness >for the GNU reimplementation of the UNIX utilities, >which have done away with maximum line sizes, but on >my Sun, I still can't vi in a 200 column xterm. Nice try, but he's using Ada.Text_IO.Get_Line, which takes a fixed length string. So he pretty much has to use a fixed size buffer. Text_IO doesn't have direct support for unbounded strings (because having it would drag the unbounded string library into almost every program, whether you used it or not). Possibly, there ought to be a Get_Line for Unbounded strings in a child package of Text_IO (but this does not exist in Ada 95). This would be quite a bit slower than the regular Get_Line for long lines, but it could be made acceptably fast for the common case of short lines. It is possible to write such a Get_Line out of the primitives in Text_IO, but the result would be unacceptably slow (because you would have to read a character at a time - you can't use Get_Line because you can't tell between the case of a line which exactly fills the buffer and a line which is too long and does not -- but in the former case, the line terminator is skipped). Randy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 23:44 ` Randy Brukardt @ 2002-02-22 0:37 ` Matthew Heaney 2002-02-22 1:12 ` Matthew Heaney 2002-02-22 2:57 ` Randy Brukardt 2002-02-22 2:47 ` Jeffrey Carter ` (2 subsequent siblings) 3 siblings, 2 replies; 42+ messages in thread From: Matthew Heaney @ 2002-02-22 0:37 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:u7b1g6cooeo49@corp.supernews.com... > It is possible to write such a > Get_Line out of the primitives in Text_IO, but the result would be > unacceptably slow (because you would have to read a character at a > time - you can't use Get_Line because you can't tell between the case of > a line which exactly fills the buffer and a line which is too long and > does not -- but in the former case, the line terminator is skipped). This statement is incorrect. You can test for this case via the predicate: if Last < Line'Last then --means we've consumed all the input Which means you can make your input buffer as large as you like. In general, you should use Get_Line this way: declare Max : constant := 80; --or whatever Line : String (1 .. Max + 1); --note value of Line'Last Last : Natural; begin loop Get_Line (Line, Last); --do something with Line (Line'First .. Last) exit when Last < Line'Last; end loop; end; You can search comp.lang.ada at google.com for several posts I've written on this very subject (search for "get_line"). --STX with Ada.Text_IO; use Ada.Text_IO; with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; procedure Test_Get_Line is Max : constant := 10; Line : String (1 .. Max + 1); Last : Natural; Buffer : Unbounded_String; begin Put ("ready: "); loop Get_Line (Line, Last); Append (Buffer, Line (Line'First .. Last)); exit when Last < Line'Last; end loop; Put_Line ("line is '" & To_String (Buffer) & "'"); end Test_Get_Line; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 0:37 ` Matthew Heaney @ 2002-02-22 1:12 ` Matthew Heaney 2002-02-22 2:57 ` Randy Brukardt 1 sibling, 0 replies; 42+ messages in thread From: Matthew Heaney @ 2002-02-22 1:12 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:u7b4d1bmd1f7ef@corp.supernews.com... > > You can search comp.lang.ada at google.com for several posts I've written on > this very subject (search for "get_line"). Actually, I forget that David hosted this article at adapower a while ago: http://www.adapower.com/lang/get_line.html ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 0:37 ` Matthew Heaney 2002-02-22 1:12 ` Matthew Heaney @ 2002-02-22 2:57 ` Randy Brukardt 2002-02-22 13:54 ` Marin David Condic 2002-02-22 15:34 ` Matthew Heaney 1 sibling, 2 replies; 42+ messages in thread From: Randy Brukardt @ 2002-02-22 2:57 UTC (permalink / raw) Matthew Heaney wrote in message ... >"Randy Brukardt" <randy@rrsoftware.com> wrote in message >news:u7b1g6cooeo49@corp.supernews.com... >> It is possible to write such a >> Get_Line out of the primitives in Text_IO, but the result would be >> unacceptably slow (because you would have to read a character at a >> time - you can't use Get_Line because you can't tell between the case of >> a line which exactly fills the buffer and a line which is too long and >> does not -- but in the former case, the line terminator is skipped). > >This statement is incorrect. Not exactly. This was true in Ada 83, but it was fixed circa 1985 (and added to the validation tests a couple of years later [AI83-00050]). There are a bunch of comments in our Text_IO implementation about this change. Still, I must be going senile: all I can imagine is that I "learned" about Get_Line when this was true (at least in the compiler I used), and haven't forgotten the "rule" even though it hasn't been true in a long time. >You can search comp.lang.ada at google.com for several posts I've written on >this very subject (search for "get_line"). Not interested; I've been using Get_Line since before you were born. :-) (OK, not really...) > loop > Get_Line (Line, Last); > Append (Buffer, Line (Line'First .. Last)); > exit when Last < Line'Last; > end loop; This is, of course, the inefficiency that I was commenting on. This would be slow, and would cause an awful lot of memory allocation and deallocation, with the possible exception of the first iteration. It would only be a good idea if the size of Line was larger than almost all expected lines. (Personally, I never use Unbounded strings, mainly because it took me years to figure out how to use regular Ada strings effectively, and Unbounded strings don't buy anything if you are used to doing that.) Randy Brukardt ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 2:57 ` Randy Brukardt @ 2002-02-22 13:54 ` Marin David Condic 2002-02-23 1:10 ` Matthew Heaney 2002-02-25 19:37 ` Randy Brukardt 2002-02-22 15:34 ` Matthew Heaney 1 sibling, 2 replies; 42+ messages in thread From: Marin David Condic @ 2002-02-22 13:54 UTC (permalink / raw) I'm curious about why you think this would be slow? (I may have to build a small chunk of code and time it! :-) In most applications I can think of, you can usually set some kind of arbitrary max sized buffer (the size of "Line" below...) that is going to accommodate most lines in your average text file. (Usually, you have some notion of the kinds of text files you want to process, right?) The presumption is that you might infrequently have to go 'round the loop a second (or third or fourth) time to glom onto the rest of the line, so for 99% (or some high percentage of the time) you're just doing a single Get_Line (is that inefficient?) and a single Append to an unbounded string (again, is that necessarily inefficient?) I've never looked into the underlying implementation of Unbounded_String in any Ada compiler, so I have no clue as to how naturally (in)efficient they may be. I'm guessing a typical implementation is going to be some collection of memory blocks strung together with pointers and some counters. Would "Append" require some huge overhead? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:u7bcro6je1h519@corp.supernews.com... > > loop > > Get_Line (Line, Last); > > Append (Buffer, Line (Line'First .. Last)); > > exit when Last < Line'Last; > > end loop; > > This is, of course, the inefficiency that I was commenting on. This > would be slow, and would cause an awful lot of memory allocation and > deallocation, with the possible exception of the first iteration. It > would only be a good idea if the size of Line was larger than almost all > expected lines. > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 13:54 ` Marin David Condic @ 2002-02-23 1:10 ` Matthew Heaney 2002-02-25 15:47 ` Marin David Condic 2002-02-25 19:37 ` Randy Brukardt 1 sibling, 1 reply; 42+ messages in thread From: Matthew Heaney @ 2002-02-23 1:10 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:a55iip$4s7$1@nh.pace.co.uk... > I've never looked into the underlying implementation of Unbounded_String in > any Ada compiler, so I have no clue as to how naturally (in)efficient they > may be. I'm guessing a typical implementation is going to be some collection > of memory blocks strung together with pointers and some counters. Would > "Append" require some huge overhead? Often you (re)allocate the internal buffer in powers of 2, so it would require only a few iterations to acquire an adequately-sized buffer. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-23 1:10 ` Matthew Heaney @ 2002-02-25 15:47 ` Marin David Condic 2002-02-26 15:58 ` Matthew Heaney 0 siblings, 1 reply; 42+ messages in thread From: Marin David Condic @ 2002-02-25 15:47 UTC (permalink / raw) Hmmmmmm... Hadn't thought of that. I could see how that might perform well for some expected usages, but might get nasty if you're doing lots of reallocating. I was thinking along the lines of making a linked list of some standard block size (like 64 bytes - 4 for a link & the rest data) which might make it quick for appending but would no doubt suffer when you try to do other things... There are no perfect answers, are there? :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Matthew Heaney" <mheaney@on2.com> wrote in message news:u7klg886r837b7@corp.supernews.com... > > Often you (re)allocate the internal buffer in powers of 2, so it would > require only a few iterations to acquire an adequately-sized buffer. > > > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-25 15:47 ` Marin David Condic @ 2002-02-26 15:58 ` Matthew Heaney 0 siblings, 0 replies; 42+ messages in thread From: Matthew Heaney @ 2002-02-26 15:58 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:a5dmb1$nb5$1@nh.pace.co.uk... > Hmmmmmm... Hadn't thought of that. I could see how that might perform well > for some expected usages, but might get nasty if you're doing lots of > reallocating. Well, hopefully it will reduce the need for reallocation. The STL vector and string classes are nice because they allow you to actually reserve a specific amount of internal memory. In the Charles library, I added a Set_Length operation to do the same thing. http://home.earthlink.net/~matthewjheaney/charles/charles-unbounded_arrays__ ads.htm http://home.earthlink.net/~matthewjheaney/charles/ http://home.earthlink.net/~matthewjheaney/charles-20020213.zip > I was thinking along the lines of making a linked list of some > standard block size (like 64 bytes - 4 for a link & the rest data) which > might make it quick for appending but would no doubt suffer when you try to > do other things... That's more or less how a deque works. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 13:54 ` Marin David Condic 2002-02-23 1:10 ` Matthew Heaney @ 2002-02-25 19:37 ` Randy Brukardt 2002-02-25 20:49 ` Marin David Condic ` (2 more replies) 1 sibling, 3 replies; 42+ messages in thread From: Randy Brukardt @ 2002-02-25 19:37 UTC (permalink / raw) Marin David Condic wrote in message ... >I'm curious about why you think this would be slow? (I may have to build a >small chunk of code and time it! :-) In most applications I can think of, >you can usually set some kind of arbitrary max sized buffer (the size of >"Line" below...) that is going to accommodate most lines in your average >text file. (Usually, you have some notion of the kinds of text files you >want to process, right?) The presumption is that you might infrequently have >to go 'round the loop a second (or third or fourth) time to glom onto the >rest of the line, so for 99% (or some high percentage of the time) you're >just doing a single Get_Line (is that inefficient?) and a single Append to >an unbounded string (again, is that necessarily inefficient?) I thought I said that if you make the buffer large enough, it wouldn't be so slow -- but it also would require a large buffer for many applications (if it didn't, there would be little reason to use unbounded strings in the first place). >I've never looked into the underlying implementation of Unbounded_String in >any Ada compiler, so I have no clue as to how naturally (in)efficient they >may be. I'm guessing a typical implementation is going to be some collection >of memory blocks strung together with pointers and some counters. Would >"Append" require some huge overhead? I can only comment on the Janus/Ada one (which may not be representative). It just allocates a string of the correct length for every operation. That is the easiest implementation (and the one that GNAT 3.14 uses), but it uses the heap a lot. Improving the performance of this library has not been a priority, as there isn't any point in trying to "optimize" it unless you have some real applications using it that are too slow. Otherwise, you run the risk of making the "average" application slower. In any case, Ada.Strings.Unbounded is inappropriate for long-running applications (such as the AdaIC web server), because continued use of the heap will eventually lead to fragmentation and memory exhaustion (and decreasing performance in a virtual memory environment). Randy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-25 19:37 ` Randy Brukardt @ 2002-02-25 20:49 ` Marin David Condic 2002-02-26 3:30 ` David Starner 2002-02-26 7:42 ` tmoran 2 siblings, 0 replies; 42+ messages in thread From: Marin David Condic @ 2002-02-25 20:49 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:u7l4ih2guo0gf6@corp.supernews.com... > > I thought I said that if you make the buffer large enough, it wouldn't > be so slow -- but it also would require a large buffer for many > applications (if it didn't, there would be little reason to use > unbounded strings in the first place). > O.K. I must have misunderstood. Clearly if you pick a buffer size that accommodates *most* of the lines you're likely to read, you'd have no real problem dealing with some small percentage of the cases where you'd have something reallocating more and more memory. > > > I can only comment on the Janus/Ada one (which may not be > representative). It just allocates a string of the correct length for > every operation. That is the easiest implementation (and the one that > GNAT 3.14 uses), but it uses the heap a lot. Improving the performance > of this library has not been a priority, as there isn't any point in > trying to "optimize" it unless you have some real applications using it > that are too slow. Otherwise, you run the risk of making the "average" > application slower. > Interesting. So in the cases where you'd be doing insertions, deletions and so forth, you'd be forcing a reallocation for every operation? Obviously, that could get expensive if you're doing a lot of string manipulation. I could imagine it being a bit more efficient if it allocated memory in blocks to enable some expansion & contraction without having to go back for more every time. > In any case, Ada.Strings.Unbounded is inappropriate for long-running > applications (such as the AdaIC web server), because continued use of > the heap will eventually lead to fragmentation and memory exhaustion > (and decreasing performance in a virtual memory environment). > If the strings you're dealing with require a lot of manipulation this would be the case. I've had apps that deal with a relatively static body of text - you may not know its initial size, but once loaded it might remain stable. Its always important to look at how it gets used and understand what the penalties are for using a given feature. I've used Unbounded_String a lot and never found it to behave poorly in the kinds of apps I've done that way. Of course, most of these didn't really stress test it - they've been pretty straightforward text manipulation things where the ease of use for Unbounded_String outweighed whatever inefficiencies may have been there. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-25 19:37 ` Randy Brukardt 2002-02-25 20:49 ` Marin David Condic @ 2002-02-26 3:30 ` David Starner 2002-02-26 15:44 ` Hyman Rosen 2002-02-26 7:42 ` tmoran 2 siblings, 1 reply; 42+ messages in thread From: David Starner @ 2002-02-26 3:30 UTC (permalink / raw) On Mon, 25 Feb 2002 13:37:51 -0600, Randy Brukardt <randy@rrsoftware.com> wrote: > I thought I said that if you make the buffer large enough, it wouldn't > be so slow -- but it also would require a large buffer for many > applications (if it didn't, there would be little reason to use > unbounded strings in the first place). Why? I can think of many cases where the normal case may be 40-50 characters, but for robustness, you need the possibility of handling lines 1500 characters long. Nobody's really concerned about the speed of the long case, so long as the the normal case is handled correctly, but the long case should be handled for robustness and generality. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-26 3:30 ` David Starner @ 2002-02-26 15:44 ` Hyman Rosen 2002-02-26 21:43 ` David Starner 0 siblings, 1 reply; 42+ messages in thread From: Hyman Rosen @ 2002-02-26 15:44 UTC (permalink / raw) David Starner wrote: > Why? I can think of many cases where the normal case may be 40-50 > characters, but for robustness, you need the possibility of handling > lines 1500 characters long. No, no, a thousand times no! If what you are writing is at all general purpose, with the inputs not strictly under your control, do the world a favor and don't limit input buffer size to any fixed value. If nothing else, fixing the buffer size means that you must introduce logic to handle the case where the input is longer. Then you have to document the limit, and document what happens in the exceptional case. It's all extra work to make the code *less* useful, so why do it that way? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-26 15:44 ` Hyman Rosen @ 2002-02-26 21:43 ` David Starner 2002-02-27 6:32 ` Hyman Rosen 0 siblings, 1 reply; 42+ messages in thread From: David Starner @ 2002-02-26 21:43 UTC (permalink / raw) On Tue, 26 Feb 2002 10:44:18 -0500, Hyman Rosen <hyrosen@mail.com> wrote: > David Starner wrote: >> Why? I can think of many cases where the normal case may be 40-50 >> characters, but for robustness, you need the possibility of handling >> lines 1500 characters long. > > No, no, a thousand times no! 1500 was meant as an arbitrarily large value. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-26 21:43 ` David Starner @ 2002-02-27 6:32 ` Hyman Rosen 2002-02-28 3:55 ` Chad R. Meiners 2002-03-05 14:36 ` Marin David Condic 0 siblings, 2 replies; 42+ messages in thread From: Hyman Rosen @ 2002-02-27 6:32 UTC (permalink / raw) David Starner wrote: > 1500 was meant as an arbitrarily large value. No arbitrary value is large enough. You *must* provide for input buffer size limited only by memory constraints, or you will cause some innocent user needless grief. As I said before, my troublesome case was a .newsrc file, plain text, where one line was several hundred thousand characters long. Fortunately, I was using tools which handled it with aplomb. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-27 6:32 ` Hyman Rosen @ 2002-02-28 3:55 ` Chad R. Meiners 2002-02-28 18:44 ` Hyman Rosen 2002-03-01 2:08 ` David Starner 2002-03-05 14:36 ` Marin David Condic 1 sibling, 2 replies; 42+ messages in thread From: Chad R. Meiners @ 2002-02-28 3:55 UTC (permalink / raw) I believe this is what David is saying. Normally when you write code to accept arbitrarily large input, you write it so that it's only constraint is memory. -CRM "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3C7C7E2D.6090602@mail.com... > David Starner wrote: > > 1500 was meant as an arbitrarily large value. > > No arbitrary value is large enough. You *must* provide > for input buffer size limited only by memory constraints, > or you will cause some innocent user needless grief. > > As I said before, my troublesome case was a .newsrc file, > plain text, where one line was several hundred thousand > characters long. Fortunately, I was using tools which > handled it with aplomb. > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-28 3:55 ` Chad R. Meiners @ 2002-02-28 18:44 ` Hyman Rosen 2002-03-02 3:25 ` Chad R. Meiners 2002-03-01 2:08 ` David Starner 1 sibling, 1 reply; 42+ messages in thread From: Hyman Rosen @ 2002-02-28 18:44 UTC (permalink / raw) Chad R. Meiners wrote: > I believe this is what David is saying. Normally when you write code to > accept arbitrarily large input, you write it so that it's only constraint is > memory. He said "1500 was meant as an arbitrarily large value". But there is no such thing as an arbitrarily large value. To deal with large input lines, you need to use some other technique, such as the recursive Get_Line. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-28 18:44 ` Hyman Rosen @ 2002-03-02 3:25 ` Chad R. Meiners 2002-03-03 8:22 ` Hyman Rosen 0 siblings, 1 reply; 42+ messages in thread From: Chad R. Meiners @ 2002-03-02 3:25 UTC (permalink / raw) Do you have any formal training in mathematics? Please do not take offense to this question, but you seem to misunderstand what is meant by the phase "for arbitrarily large values of x". -CRM "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3C7E7A76.6030402@mail.com... > Chad R. Meiners wrote: > > I believe this is what David is saying. Normally when you write code to > > accept arbitrarily large input, you write it so that it's only constraint is > > memory. > > He said "1500 was meant as an arbitrarily large value". But there > is no such thing as an arbitrarily large value. To deal with large > input lines, you need to use some other technique, such as the > recursive Get_Line. > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-03-02 3:25 ` Chad R. Meiners @ 2002-03-03 8:22 ` Hyman Rosen 2002-03-03 17:50 ` Chad R. Meiners 0 siblings, 1 reply; 42+ messages in thread From: Hyman Rosen @ 2002-03-03 8:22 UTC (permalink / raw) Chad R. Meiners wrote: > Do you have any formal training in mathematics? Please do not take offense > to this question, but you seem to misunderstand what is meant by the phase > "for arbitrarily large values of x". Oh, I see I misunderstood what David Starner was saying - my bad. He didn't mean "use 1500 when typical size is 40 or 50", he meant "be prepared for arbitrarily large input, with 1500 as a sample". I have a degree in engineering, and the math to go with it. I do know what "for arbitrarily large values of x" means, but I seem to have trouble parsing English. Hey, maybe it's time to start the thread on the difference between arbitrary and random! :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-03-03 8:22 ` Hyman Rosen @ 2002-03-03 17:50 ` Chad R. Meiners 0 siblings, 0 replies; 42+ messages in thread From: Chad R. Meiners @ 2002-03-03 17:50 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3C81DDFA.8090306@mail.com... > Hey, maybe it's time to start the thread on the difference between > arbitrary and random! :-) > :-) Perhaps, but then you have to mark it off topic. ;-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-28 3:55 ` Chad R. Meiners 2002-02-28 18:44 ` Hyman Rosen @ 2002-03-01 2:08 ` David Starner 1 sibling, 0 replies; 42+ messages in thread From: David Starner @ 2002-03-01 2:08 UTC (permalink / raw) On Wed, 27 Feb 2002 22:55:40 -0500, Chad R. Meiners <crmeiners@hotmail.com> wrote: > I believe this is what David is saying. Normally when you write code to > accept arbitrarily large input, you write it so that it's only constraint is > memory. Exactly. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-27 6:32 ` Hyman Rosen 2002-02-28 3:55 ` Chad R. Meiners @ 2002-03-05 14:36 ` Marin David Condic 1 sibling, 0 replies; 42+ messages in thread From: Marin David Condic @ 2002-03-05 14:36 UTC (permalink / raw) I think the situation would be to use something like a 1500 character buffer & go 'round the block to reallocate the Unbounded_String if and only if the line length exceeded the 1500 characters. That way, the only time you'd force any reallocations upon appending to the Unbounded_String would be the case where the line length is greater than the 1500 characters of the buffer. It would perform fast for most of the cases and probably wouldn't perform too bad for the few cases where the line exceeded the buffer. If you're going to Text_IO, you really need to have some kind of fixed length string into which you read. Hence the need for *some* buffer limit - but not necessarly a limit on the line length of the what the program can accept. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3C7C7E2D.6090602@mail.com... > David Starner wrote: > > 1500 was meant as an arbitrarily large value. > > No arbitrary value is large enough. You *must* provide > for input buffer size limited only by memory constraints, > or you will cause some innocent user needless grief. > > As I said before, my troublesome case was a .newsrc file, > plain text, where one line was several hundred thousand > characters long. Fortunately, I was using tools which > handled it with aplomb. > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-25 19:37 ` Randy Brukardt 2002-02-25 20:49 ` Marin David Condic 2002-02-26 3:30 ` David Starner @ 2002-02-26 7:42 ` tmoran 2 siblings, 0 replies; 42+ messages in thread From: tmoran @ 2002-02-26 7:42 UTC (permalink / raw) > continued use of the heap will eventually lead to fragmentation and > memory exhaustion Only if you use an inappropriate variety of memory management. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 2:57 ` Randy Brukardt 2002-02-22 13:54 ` Marin David Condic @ 2002-02-22 15:34 ` Matthew Heaney 1 sibling, 0 replies; 42+ messages in thread From: Matthew Heaney @ 2002-02-22 15:34 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:u7bcro6je1h519@corp.supernews.com... > > > loop > > Get_Line (Line, Last); > > Append (Buffer, Line (Line'First .. Last)); > > exit when Last < Line'Last; > > end loop; > > This is, of course, the inefficiency that I was commenting on. No, the inefficiency you were commenting on was the size of the string buffer Line, which you said had to be one. That is wrong -- as in my example, it can be of arbitrary size. > This would be slow, and would cause an awful lot of memory allocation and > deallocation, with the possible exception of the first iteration. Well, the inefficiency of appending to an Unbounded_String is a separate issue. We were talking about the inefficiency of Get_Line. If you don't like Unbounded_String, then use another data structure. > It would only be a good idea if the size of Line was larger than almost all > expected lines. Fine, then declare a large size for Line. I typically use 81 or 133, when reading text from standard input. > (Personally, I never use Unbounded strings, mainly because it took me > years to figure out how to use regular Ada strings effectively, and > Unbounded strings don't buy anything if you are used to doing that.) If Unbounded_String offends you, then use a recursive implementation to return an unconstrained String. Or use another data structure. The point is that of course you can distinguish when you've consumed the entire input line. My example illustrates the standard idiom, per AI-50. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 23:44 ` Randy Brukardt 2002-02-22 0:37 ` Matthew Heaney @ 2002-02-22 2:47 ` Jeffrey Carter 2002-02-22 13:41 ` Marin David Condic 2002-02-22 16:27 ` Hyman Rosen 3 siblings, 0 replies; 42+ messages in thread From: Jeffrey Carter @ 2002-02-22 2:47 UTC (permalink / raw) Randy Brukardt wrote: > > you can't use Get_Line because you can't tell between the case of > a line which exactly fills the buffer and a line which is too long and > does not -- but in the former case, the line terminator is skipped). This is a curious statement to be coming from the Keeper of Ada-Auth and developer of Janus Ada. Get_Line does not skit the line terminator if the string is completely filled. A.10.7 says Get_Line Reads successive characters from the specified input file and assigns them to successive characters of the specified string. Reading stops if the end of the string is met. Reading also stops if the end of the line is met before meeting the end of the string; in this case Skip_Line is (in effect) called with a spacing of 1. The values of characters not assigned are not specified. Any implementation that skips the line terminator when the string is completely filled is clearly incorrect. WWJD? (What Would Janus Do?) -- Jeff Carter "You cheesy lot of second-hand electric donkey-bottom biters." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 23:44 ` Randy Brukardt 2002-02-22 0:37 ` Matthew Heaney 2002-02-22 2:47 ` Jeffrey Carter @ 2002-02-22 13:41 ` Marin David Condic 2002-02-23 1:08 ` Matthew Heaney 2002-02-23 2:03 ` Jeffrey Carter 2002-02-22 16:27 ` Hyman Rosen 3 siblings, 2 replies; 42+ messages in thread From: Marin David Condic @ 2002-02-22 13:41 UTC (permalink / raw) Wait a minute...... I seem to recall a nifty example of how you could return an arbitrary length string from a function that used Get/Get_Line (?) and recursed in the event that the line was longer than the buffer. It might be in a code example somewhere like on AdaPower? If you can do that, why not a similar subprogram for Unbounded_String? It would be even easier and not require recursion since you could just keep reading some arbitrary sized buffer in a loop and appending it to an Unbounded_String that is returned to the caller. Speed may be an issue, but with a reasonably large buffer, I don't think it would be unacceptably slow. Why would you have to read it one character at a time? (I will admit that I have not tried anything like this, so there may be some tiny devil in the details that I'm missing...) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:u7b1g6cooeo49@corp.supernews.com... > > Text_IO doesn't have direct support for unbounded strings (because > having it would drag the unbounded string library into almost every > program, whether you used it or not). Possibly, there ought to be a > Get_Line for Unbounded strings in a child package of Text_IO (but this > does not exist in Ada 95). This would be quite a bit slower than the > regular Get_Line for long lines, but it could be made acceptably fast > for the common case of short lines. It is possible to write such a > Get_Line out of the primitives in Text_IO, but the result would be > unacceptably slow (because you would have to read a character at a > time - you can't use Get_Line because you can't tell between the case of > a line which exactly fills the buffer and a line which is too long and > does not -- but in the former case, the line terminator is skipped). > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 13:41 ` Marin David Condic @ 2002-02-23 1:08 ` Matthew Heaney 2002-02-23 2:03 ` Jeffrey Carter 1 sibling, 0 replies; 42+ messages in thread From: Matthew Heaney @ 2002-02-23 1:08 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:a55hpd$4cp$1@nh.pace.co.uk... > Wait a minute...... I seem to recall a nifty example of how you could return > an arbitrary length string from a function that used Get/Get_Line (?) and > recursed in the event that the line was longer than the buffer. It might be > in a code example somewhere like on AdaPower? declare function Get_Line return String is Line : String (1 .. 80 + 1); Last : Natural; begin Text_IO.Get_Line (Line, Last); if Last < Line'Last then return Line (Line'First .. Last); else return Line & Get_Line; end if; end Get_Line; Line : constant String := Get_Line; begin Put_Line (Line); end; > If you can do that, why not a > similar subprogram for Unbounded_String? It would be even easier and not > require recursion since you could just keep reading some arbitrary sized > buffer in a loop and appending it to an Unbounded_String that is returned to > the caller. I showed this in my last post. > Speed may be an issue, but with a reasonably large buffer, I don't think it > would be unacceptably slow. Why would you have to read it one character at a > time? No, you don't have to read one character at a time, as is shown above. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-22 13:41 ` Marin David Condic 2002-02-23 1:08 ` Matthew Heaney @ 2002-02-23 2:03 ` Jeffrey Carter 1 sibling, 0 replies; 42+ messages in thread From: Jeffrey Carter @ 2002-02-23 2:03 UTC (permalink / raw) Marin David Condic wrote: > > Wait a minute...... I seem to recall a nifty example of how you could return > an arbitrary length string from a function that used Get/Get_Line (?) and > recursed in the event that the line was longer than the buffer. It might be > in a code example somewhere like on AdaPower? If you can do that, why not a > similar subprogram for Unbounded_String? It would be even easier and not > require recursion since you could just keep reading some arbitrary sized > buffer in a loop and appending it to an Unbounded_String that is returned to > the caller. Such as function PragmARC.Get_Line? It uses a String of only 100 characters, yet still avoids recursion in most applications. A procedure that built a result in a mode in out [Un]Bounded_String parameter is perfectly doable would not need to be recursive. But the point of a Get_Line function, which dates from the days of Ada 83 (see "Variable-Length String Input in Ada" by J. Carter in ADA LETTERS, 1989 May/Jun), is that you rarely need a variable string abstraction in Ada if you really understand how to use one-dimensional arrays in Ada. -- Jeff Carter "You cheesy lot of second-hand electric donkey-bottom biters." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 23:44 ` Randy Brukardt ` (2 preceding siblings ...) 2002-02-22 13:41 ` Marin David Condic @ 2002-02-22 16:27 ` Hyman Rosen 3 siblings, 0 replies; 42+ messages in thread From: Hyman Rosen @ 2002-02-22 16:27 UTC (permalink / raw) Randy Brukardt wrote: > Nice try, but he's using Ada.Text_IO.Get_Line, which takes a fixed > length string. So he pretty much has to use a fixed size buffer. I was commenting on code in general, not his specifically. But in any case, what kind of an attitude is this? "We're going to do it wrong because the language primitives make it easier to do it that way."? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 18:28 ` Hyman Rosen 2002-02-21 23:44 ` Randy Brukardt @ 2002-02-21 23:49 ` unversedangel 1 sibling, 0 replies; 42+ messages in thread From: unversedangel @ 2002-02-21 23:49 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C753C66.8020509@mail.com>... > Unversed Angel wrote: > > Line_Buffer : String (1 .. 1000); > Unless you have very domain-specific information, > using a fixed-size input buffer is an invitation > to errors. You will never pick a large-enough size. I had already realised that unbounded_strings were the best way to go but i have no idea what to do next as this program will not compile. with Text_io; use Text_io; procedure main is ---pre: text is in the mark up language ---post: text has been converted to english ---test: once thru procedure Get_line is ---pre:text needs to be input ---post:text has been input ---test: once thru Line_Buffer : String(Unbounded_String); Line_Length : Natural range 0 .. Line_Buffer'Last; Line_Store : array (1 .. 10_000) of Unbounded_String; Line_Count : Natural range 0 .. Line_Store'Last; begin loop Get_Line (Line_Buffer, Line_Length); Line_Count := Line_Count + 1; Line_Store (Line_Count) := To_Unbounded_String (Line_Buffer (1 .. Line_Length)); new_line; end loop; end; Procedure doubleslash is ---pre:mark up language has been input ---post:doubleslash has been converted to single slash ---test: /,//,/// begin Loop For i in s'range loop if s(i)="//" then s:='/'; end if; end loop; end; procedure unformatted is ---pre: mark up language has been input ---post:/N tag has left the text formatted as it was ---test: /N, /N/N,/N/U Loop For i in s'range loop if s(i)=/N then do nothing elseif exit end if; end if; end_loop; End; Begin --of main s:string; Put("Please enter text: "); Get_Line(s); doubleslash; unformatted; end; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 18:07 ` Unversed Angel 2002-02-21 18:28 ` Hyman Rosen @ 2002-02-21 22:48 ` unversedangel 2002-02-21 23:14 ` Hyman Rosen 2002-02-22 14:11 ` Marin David Condic 1 sibling, 2 replies; 42+ messages in thread From: unversedangel @ 2002-02-21 22:48 UTC (permalink / raw) unversedangel@aol.com (Unversed Angel) wrote in message news:<20020221130715.12738.00000034@mb-bg.aol.com>... i thought of an unbounded string but the program will not go through the compiler, no matter which one i use or how i change the program. with Text_io; use Text_io; procedure main is ---pre: text is in the mark up language ---post: text has been converted to english ---test: once thru procedure Get_line is ---pre:text needs to be input ---post:text has been input ---test: once thru Line_Buffer : String(Unbounded_String); Line_Length : Natural range 0 .. Line_Buffer'Last; Line_Store : array (1 .. 10_000) of Unbounded_String; Line_Count : Natural range 0 .. Line_Store'Last; begin loop Get_Line (Line_Buffer, Line_Length); Line_Count := Line_Count + 1; Line_Store (Line_Count) := To_Unbounded_String (Line_Buffer (1 .. Line_Length)); new_line; end loop; end; Procedure doubleslash is ---pre:mark up language has been input ---post:doubleslash has been converted to single slash ---test: /,//,/// begin Loop For i in s'range loop if s(i)="//" then s:='/'; end if; end loop; end; procedure unformatted is ---pre: mark up language has been input ---post:/N tag has left the text formatted as it was ---test: /N, /N/N,/N/U Loop For i in s'range loop if s(i)=/N then do nothing elseif exit end if; end if; end_loop; End; Begin --of main s:string; Put("Please enter text: "); Get_Line(s); doubleslash; unformatted; end; -------------------Target: Win32 (Intel) Debug-------------------- main.adb: Error: line 11 col 23 LRM:4.1(3), Direct name, Unbounded_String, is not visible, Ignoring future references main.adb: Error: line 11 col 40 LRM:3.3.1(5), an object declaration with an indefinite subtype must have an initialization expression, continuing main.adb: Error: line 20 col 7 LRM:4.1(3), Direct name, To_Unbounded_String, is not visible, Ignoring future references main.adb: Error: line 31 col 12 LRM:4.1(3), Direct name, s, is not visible, Ignoring future references main.adb: Error: line 36 col 1 Parse error: expected END_LOOP, got END, Skipping up to semicolon main.adb: Error: line 38 col 1 LRM:5.1(2), Parse error expecting statement got PROCEDURE, skipping to after next semicolon main.adb: Error: line 48 col 5 Parse error: expected END, got END_IF, Inserting END main.adb: Error: line 48 col 5 Parse error: expected SEMICOLON, got END_IF, Inserting SEMICOLON main.adb: Error: line 48 col 5 LRM:3.1(3), Parse error expecting declaration got END_IF, Skipping to after next semicolon main.adb: Error: line 49 col 11 Parse error: expected COLON, got SEMICOLON, Inserting COLON main.adb: Error: line 49 col 11 LRM:4.1(2), Syntax error: the token SEMICOLON can not be used as a name, skipping to next separator main.adb: Error: line 50 col 1 Parse error: expected BEGIN, got END, Inserting BEGIN main.adb: Error: line 50 col 1 LRM:5.1(2), Unexpected ending token END where statement is required, continuing main.adb: Error: line 52 col 1 LRM:10.1.1(5), BEGIN is unexpected here, Continuing main.adb: Error: line 53 col 6 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 53 col 7 LRM:10.1.1(5), COLON is unexpected here, Continuing main.adb: Error: line 53 col 8 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 53 col 14 LRM:10.1.1(5), SEMICOLON is unexpected here, Continuing main.adb: Error: line 54 col 1 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 54 col 4 LRM:10.1.1(5), LEFT PARENTHESIS is unexpected here, Continuing main.adb: Error: line 54 col 5 LRM:10.1.1(5), Character String is unexpected here, Continuing main.adb: Error: line 54 col 26 LRM:10.1.1(5), RIGHT PARENTHESIS is unexpected here, Continuing main.adb: Error: line 54 col 27 LRM:10.1.1(5), SEMICOLON is unexpected here, Continuing main.adb: Error: line 55 col 1 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 55 col 9 LRM:10.1.1(5), LEFT PARENTHESIS is unexpected here, Continuing main.adb: Error: line 55 col 10 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 55 col 11 LRM:10.1.1(5), RIGHT PARENTHESIS is unexpected here, Continuing main.adb: Error: line 55 col 12 LRM:10.1.1(5), SEMICOLON is unexpected here, Continuing main.adb: Error: line 56 col 1 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 56 col 12 LRM:10.1.1(5), SEMICOLON is unexpected here, Continuing main.adb: Error: line 57 col 1 LRM:10.1.1(5), Identifier is unexpected here, Continuing main.adb: Error: line 57 col 12 LRM:10.1.1(5), SEMICOLON is unexpected here, Continuing main.adb: Error: line 58 col 1 LRM:10.1.1(5), END is unexpected here, Continuing main.adb: Error: line 58 col 4 LRM:10.1.1(5), SEMICOLON is unexpected here, Continuing Front end of ..\..\..\..\my documents\cs131\main.adb failed with 34 errors. (0 Warnings) Tool execution failed. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 22:48 ` unversedangel @ 2002-02-21 23:14 ` Hyman Rosen 2002-02-22 14:11 ` Marin David Condic 1 sibling, 0 replies; 42+ messages in thread From: Hyman Rosen @ 2002-02-21 23:14 UTC (permalink / raw) unversedangel@aol.com wrote: > unversedangel@aol.com (Unversed Angel) wrote in message > news:<20020221130715.12738.00000034@mb-bg.aol.com>... > i thought of an unbounded string but the program will not go through > the compiler, no matter which one i use or how i change the program. You clearly have no clue as to what you are doing. Did you perhaps not bother to attend or pay attention to your classes? Did you not bother to read or understand your textbook? No one here is going to do your homework for you. I suspect most readers of this newsgroup hope you will fail, so that they will never have to encounter you at work! Computer programs are not clay, to be pushed and prodded until they fit through an opening. They are built with intention and design, by people who understand what they are doing and the tools they are using. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: functions, packages & characters 2002-02-21 22:48 ` unversedangel 2002-02-21 23:14 ` Hyman Rosen @ 2002-02-22 14:11 ` Marin David Condic 1 sibling, 0 replies; 42+ messages in thread From: Marin David Condic @ 2002-02-22 14:11 UTC (permalink / raw) You seem to be missing some fundamental concepts of Ada - and possibly programming in general. Type checking is your problem here and that is something lots of languages do - not just Ada. One type is not interchangeable with another - that's the whole reason for their existence. A String is not identical to a Character so you have assignments and comparisons that are incorrect. You really should spend some time looking at one of the Ada books or tutorials that have been recommended. Barring that, you ought to be making better use of your compiler. It undoubtedly is outputting error messages that will help you figure out what is going on. If you can't figure out what the error messages are telling you, you could post the relavent code snippets here & possibly get a more detailed explanation. You don't say what compiler you are using, but if you are using Gnat, try the following command line options: gnatmake -gnatvl <your_program_name_here> That will give you verbose error messages and a program listing that may be helpful when posting questions. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ <unversedangel@aol.com> wrote in message news:dcb99faa.0202211448.537be1d4@posting.google.com... > unversedangel@aol.com (Unversed Angel) wrote in message news:<20020221130715.12738.00000034@mb-bg.aol.com>... > i thought of an unbounded string but the program will not go through > the compiler, no matter which one i use or how i change the program. > > > with Text_io; use Text_io; > procedure main is > ---pre: text is in the mark up language > ---post: text has been converted to english > ---test: once thru > > procedure Get_line is > ---pre:text needs to be input > ---post:text has been input > ---test: once thru > Line_Buffer : String(Unbounded_String); > Line_Length : Natural range 0 .. Line_Buffer'Last; > Line_Store : array (1 .. 10_000) of Unbounded_String; > Line_Count : Natural range 0 .. Line_Store'Last; > begin > loop > Get_Line (Line_Buffer, Line_Length); > Line_Count := Line_Count + 1; > Line_Store (Line_Count) := > To_Unbounded_String (Line_Buffer (1 .. Line_Length)); > new_line; > end loop; > end; > > Procedure doubleslash is > ---pre:mark up language has been input > ---post:doubleslash has been converted to single slash > ---test: /,//,/// > begin > Loop > For i in s'range loop > if s(i)="//" then > s:='/'; > end if; > end loop; > end; > > procedure unformatted is > ---pre: mark up language has been input > ---post:/N tag has left the text formatted as it was > ---test: /N, /N/N,/N/U > Loop > For i in s'range loop > if s(i)=/N then > do nothing > elseif exit > end if; > end if; > end_loop; > End; > > Begin --of main > s:string; > Put("Please enter text: "); > Get_Line(s); > doubleslash; > unformatted; > end; > -------------------Target: Win32 (Intel) Debug-------------------- > main.adb: Error: line 11 col 23 LRM:4.1(3), Direct name, > Unbounded_String, is not visible, Ignoring future references > > main.adb: Error: line 11 col 40 LRM:3.3.1(5), an object declaration > with an indefinite subtype must have an initialization expression, > continuing > > main.adb: Error: line 20 col 7 LRM:4.1(3), Direct name, > To_Unbounded_String, is not visible, Ignoring future references > > main.adb: Error: line 31 col 12 LRM:4.1(3), Direct name, s, is not > visible, Ignoring future references > > main.adb: Error: line 36 col 1 Parse error: expected END_LOOP, got > END, Skipping up to semicolon > > main.adb: Error: line 38 col 1 LRM:5.1(2), Parse error expecting > statement got PROCEDURE, skipping to after next semicolon > > main.adb: Error: line 48 col 5 Parse error: expected END, got END_IF, > Inserting END > > main.adb: Error: line 48 col 5 Parse error: expected SEMICOLON, got > END_IF, Inserting SEMICOLON > > main.adb: Error: line 48 col 5 LRM:3.1(3), Parse error expecting > declaration got END_IF, Skipping to after next semicolon > > main.adb: Error: line 49 col 11 Parse error: expected COLON, got > SEMICOLON, Inserting COLON > > main.adb: Error: line 49 col 11 LRM:4.1(2), Syntax error: the token > SEMICOLON can not be used as a name, skipping to next separator > > main.adb: Error: line 50 col 1 Parse error: expected BEGIN, got END, > Inserting BEGIN > > main.adb: Error: line 50 col 1 LRM:5.1(2), Unexpected ending token END > where statement is required, continuing > > main.adb: Error: line 52 col 1 LRM:10.1.1(5), BEGIN is unexpected > here, Continuing > > main.adb: Error: line 53 col 6 LRM:10.1.1(5), Identifier is unexpected > here, Continuing > > main.adb: Error: line 53 col 7 LRM:10.1.1(5), COLON is unexpected > here, Continuing > > main.adb: Error: line 53 col 8 LRM:10.1.1(5), Identifier is unexpected > here, Continuing > > main.adb: Error: line 53 col 14 LRM:10.1.1(5), SEMICOLON is unexpected > here, Continuing > > main.adb: Error: line 54 col 1 LRM:10.1.1(5), Identifier is unexpected > here, Continuing > > main.adb: Error: line 54 col 4 LRM:10.1.1(5), LEFT PARENTHESIS is > unexpected here, Continuing > > main.adb: Error: line 54 col 5 LRM:10.1.1(5), Character String is > unexpected here, Continuing > > main.adb: Error: line 54 col 26 LRM:10.1.1(5), RIGHT PARENTHESIS is > unexpected here, Continuing > > main.adb: Error: line 54 col 27 LRM:10.1.1(5), SEMICOLON is unexpected > here, Continuing > > main.adb: Error: line 55 col 1 LRM:10.1.1(5), Identifier is unexpected > here, Continuing > > main.adb: Error: line 55 col 9 LRM:10.1.1(5), LEFT PARENTHESIS is > unexpected here, Continuing > > main.adb: Error: line 55 col 10 LRM:10.1.1(5), Identifier is > unexpected here, Continuing > > main.adb: Error: line 55 col 11 LRM:10.1.1(5), RIGHT PARENTHESIS is > unexpected here, Continuing > > main.adb: Error: line 55 col 12 LRM:10.1.1(5), SEMICOLON is unexpected > here, Continuing > > main.adb: Error: line 56 col 1 LRM:10.1.1(5), Identifier is unexpected > here, Continuing > > main.adb: Error: line 56 col 12 LRM:10.1.1(5), SEMICOLON is unexpected > here, Continuing > > main.adb: Error: line 57 col 1 LRM:10.1.1(5), Identifier is unexpected > here, Continuing > > main.adb: Error: line 57 col 12 LRM:10.1.1(5), SEMICOLON is unexpected > here, Continuing > > main.adb: Error: line 58 col 1 LRM:10.1.1(5), END is unexpected here, > Continuing > > main.adb: Error: line 58 col 4 LRM:10.1.1(5), SEMICOLON is unexpected > here, Continuing > > Front end of ..\..\..\..\my documents\cs131\main.adb failed with 34 > errors. (0 Warnings) > Tool execution failed. ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2002-03-05 14:36 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-02-21 0:16 functions, packages & characters Unversed Angel 2002-02-21 0:37 ` tmoran 2002-02-21 1:13 ` Unversed Angel 2002-02-21 2:53 ` tmoran 2002-02-21 8:25 ` Unversed Angel 2002-02-21 13:47 ` Marin David Condic 2002-02-22 0:22 ` tmoran -- strict thread matches above, loose matches on Subject: below -- 2002-02-21 8:59 Christoph Grein 2002-02-21 18:07 ` Unversed Angel 2002-02-21 18:28 ` Hyman Rosen 2002-02-21 23:44 ` Randy Brukardt 2002-02-22 0:37 ` Matthew Heaney 2002-02-22 1:12 ` Matthew Heaney 2002-02-22 2:57 ` Randy Brukardt 2002-02-22 13:54 ` Marin David Condic 2002-02-23 1:10 ` Matthew Heaney 2002-02-25 15:47 ` Marin David Condic 2002-02-26 15:58 ` Matthew Heaney 2002-02-25 19:37 ` Randy Brukardt 2002-02-25 20:49 ` Marin David Condic 2002-02-26 3:30 ` David Starner 2002-02-26 15:44 ` Hyman Rosen 2002-02-26 21:43 ` David Starner 2002-02-27 6:32 ` Hyman Rosen 2002-02-28 3:55 ` Chad R. Meiners 2002-02-28 18:44 ` Hyman Rosen 2002-03-02 3:25 ` Chad R. Meiners 2002-03-03 8:22 ` Hyman Rosen 2002-03-03 17:50 ` Chad R. Meiners 2002-03-01 2:08 ` David Starner 2002-03-05 14:36 ` Marin David Condic 2002-02-26 7:42 ` tmoran 2002-02-22 15:34 ` Matthew Heaney 2002-02-22 2:47 ` Jeffrey Carter 2002-02-22 13:41 ` Marin David Condic 2002-02-23 1:08 ` Matthew Heaney 2002-02-23 2:03 ` Jeffrey Carter 2002-02-22 16:27 ` Hyman Rosen 2002-02-21 23:49 ` unversedangel 2002-02-21 22:48 ` unversedangel 2002-02-21 23:14 ` Hyman Rosen 2002-02-22 14:11 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox