From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3ea3c3aa71aa3a1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-25 09:57:31 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news.telebyte.nl!fu-berlin.de!uni-berlin.de!82-43-33-254.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Questions Date: Fri, 25 Apr 2003 17:57:38 +0100 Message-ID: References: <69uaavobiedlcb4gr0lro4t41nu41t2k2f@4ax.com> NNTP-Posting-Host: 82-43-33-254.cable.ubr01.croy.blueyonder.co.uk (82.43.33.254) X-Trace: fu-berlin.de 1051289849 8718360 82.43.33.254 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:36553 Date: 2003-04-25T17:57:38+01:00 List-Id: "Robert A Duff" wrote in message news:wcc7k9mi4rb.fsf@shell01.TheWorld.com... > Jakub Zawadzki writes: > > > It's guestions from my friend > > Emaix>I have a question. Does a String(1..X) occupy X bytes always, no > > Emaix> matter what actual length the string has got? > > Heh? The length of the string *is* X. So yes, it occupies X bytes > (plus whatever dope is necessary). Sometimes a srting such as, for example, defined by String(1..10), will occupy 20 or 40 bytes (plus 'dope information'), unless pragma Pack is applied to it. This is because normally the compiler will allocate one 'storage element' per character (so as to maximise speed of access to it) and on some target machines storage elements are 16 or 32 bits in size. (Some unusual machines have other sizes of storage element.) The 'dope' information effectively includes the bounds of the array (the 1 and the 10 in my example), but not necessarily in that form. Sometimes dope the information has to be stored in memory, sometimes it doesn't. Often the dope information is not stored in the same place as the array contents (the characters), and often things are done with the dope information which are not done with the contents. I'm afraid the full story about dope information is very complex. A string such as defined by String(1..10) is called a 'fixed-length' string. Generally it is considered to have the bounds 1 and 10 (and so length 10) permanently. However, sometimes the 'actual length' of a fixed-length string is considered to be all the characters in the string minus any trailing spaces (or NULs). In which case the answer, in essence, to the original question is "yes": if I declare My_Name: String(1..10) := "Nick "; His_Name: String(1..10) := "Robert "; then the contents of My_Name will normally occupy the same amount of space in memory as His_Name, even though the actual length (as just defined) of My_Name is 4 and of His_Name is 6. The compiler simply stores the trailing spaces as ordinary characters. > >...Second: do > > Emaix>To_String and To_Unbounded_String conversions copy strings > > Probably. To expand on that reply a little, for both operations (Ada.Strings.Unbounded_Strings.To_String and Ada.Strings.Unbounded_Strings.To_Unbounded_String): * Some implementations may only copy a pointer (and may also need to update certain internal counters), but this will be rare. * Most of the time there will be a simple copy of all the contents (the characters) of the source string. * In some cases it may be necessary to do more than just copying. For example, sometimes it will be necessary to 'pack' or 'unpack' the characters, as well as copying them. For To_Unbounded_String, most implementations will need to do two things: firstly, allocating a space on 'the heap' (and updating a pointer to it); secondly, copying the contents (characters) of the source string into that space. I hope this is of some help! -- Nick Roberts Jabber: debater@charente.de [ICQ: 159718630]