!standard A.4.3(00) 05-10-21 AC95-00114/01 !standard A.4.4(00) !standard A.4.5(00) !class Amendment 05-10-21 !status received no action 05-10-21 !status received 05-01-31 !subject Generic versions of Ada.Strings packages !summary !appendix From: Robert Dewar Date: Monday, January 31, 2005 7:29 AM with the addition of wide_wide, there is a lot of code duplication between normal/wide/wide_wide versions. I am considering introducing a single generic in some cases, with three instantiations: 1. Less code duplication 2. Interesting capability for user to instantiate with other than Character, Wide_Character or Wide_Wide_Character Unbounded_Integer_Lists seem like an interesting thing to me Was this possibility ever discussed? **************************************************************** From: Pascal Leroy Date: Monday, January 31, 2005 7:53 AM > with the addition of wide_wide, there is a lot of code > duplication between normal/wide/wide_wide versions. I am > considering introducing a single generic in some cases, with > three instantiations: > > 1. Less code duplication > 2. Interesting capability for user to instantiate with other than > Character, Wide_Character or Wide_Wide_Character Interestingly enough, that's how our current implementation of the Character and Wide_Character works internally, and we will build on top of that for Wide_Wide_Character. As I recall (I didn't look at the code recently) this is all generic, except for two special cases: 1 - I/O on wide files typically involves some kind encoding (UTF, UCS, JIS, etc.) while I/O on normal character files doesn't. 2 - Character sets and maps are represented as arrays, while Wide_Character sets use some more fancy data structures with indirections (gosh, I can't for the life of me remember how that works). > Unbounded_Integer_Lists seem like an interesting thing to me > > Was this possibility ever discussed? No, I don't think so. And given past experience, it's way too late to add predefined units at this point. However, this could be introduced as part of an extension to the predefined library, outside of the Amendment process (we gave a lot of thought to leaving the door opened to extensions when we designed the containers). **************************************************************** From: Robert Dewar Date: Monday, January 31, 2005 11:22 AM > No, I don't think so. And given past experience, it's way too late to add > predefined units at this point. However, this could be introduced as part > of an extension to the predefined library, outside of the Amendment > process (we gave a lot of thought to leaving the door opened to extensions > when we designed the containers). There is no limitation on adding grandchildren anyway, so you could certainly add Ada.Strings.Generic_Unbounded. I think I will go ahead and do it, no reason not to! **************************************************************** From: Randy Brukardt Date: Monday, January 31, 2005 4:53 PM > Unbounded_Integer_Lists seem like an interesting thing to me Ada 2005 has that, it's called Containers.Vectors (Integer). Matt tried as much as made sense to copy the design of Ada.Strings.Unbounded when he designed Containers.Vectors -- it doesn't have every possible operation, but it has the ones you are most likely to use. You could even use it as better abstracted version of Ada.Strings.Unbounded if you wanted to (the "&" operators and constructor functions are supported). As far as a generic version of Unbounded_Strings goes, Dr. Leif suggested that years ago. Probably other people have, too. I would be very opposed to a generic being the only thing supported. It would be unnecessarily hard to use and unnecessarily expensive in our implementation (each character would have take up maximum size, which would require a shape conversion and thunk access to them). Assuming appropriate nongeneric equivalents are defined, I would grudgingly agree to it. But I do think it is a bit late to do so, and I'm pretty sure you'd find it's not quite right to do (certainly not for Wide_Text_IO, and probably not in a number of other cases as well) - at least without adjustment of the semantics and wording. **************************************************************** From: Robert Dewar Date: Wednesday, February 2, 2005 9:18 AM > I would be very opposed to a generic being the only thing supported. It > would be unnecessarily hard to use and unnecessarily expensive in our > implementation (each character would have take up maximum size, which would > require a shape conversion and thunk access to them). Assuming appropriate > nongeneric equivalents are defined, I would grudgingly agree to it. Yes, of course nongeneric equivalents are defined, that has to be the case for back compatibility. > > But I do think it is a bit late to do so, and I'm pretty sure you'd find > it's not quite right to do (certainly not for Wide_Text_IO, and probably not > in a number of other cases as well) - at least without adjustment of the > semantics and wording. It's useless in the Text_IO case, but it is useful for the string packages case, and I have noted it down as an enhancement we will implement for GNAT (we don't need it to be in the standard for that :-) ****************************************************************