comp.lang.ada
 help / color / mirror / Atom feed
From: Natasha Kerensikova <lithiumcat@gmail.com>
Subject: String_Holder ?
Date: Sun, 18 Dec 2011 12:34:41 +0000 (UTC)
Date: 2011-12-18T12:34:41+00:00	[thread overview]
Message-ID: <slrnjerndj.1lme.lithiumcat@sigil.instinctive.eu> (raw)

Hello,

in my few Ada projects so far, I have quite often encountered the need
of storing a string along with other information in records. So I went
for discriminants containing the string size, and putting the string
directly in the record.

This works well when there is only one or two strings, but with several
of them, or in variant records, I find it quite heavy. So I was thinking
about something like that:


type String_Holder is still to be defined;

function Hold (S : String) return String_Holder;

function To_String (Holder : String_Holder) return String;

procedure Query (Holder : String_Holder;
                 Process : not null access procedure (S : String));


I'm still unsure on what kind of type String_Holder should be (private,
tagged private or interface). It would basically be a constant-size
reference to an immutable string that is stored "somewhere".

The simplest implementation would be an Unbounded_String, though if
needed it could be improved reference counting to make assignments
cheaper, or with a hash table to deduplicate identical strings, etc.

So my question is, does it make sense to have such objects? Or am I
getting blinded by my C past, where strings are always manipulated
through a char* object?

Assuming it does make sense, am I right in thinking it's better to have
such a type, even if it's a thin wrapper around Unbounded_String,
instead of using directly Unbounded_String?

Assuming it does make sense to have a String_Holder, would it be better
to have it private, tagged private or interface?
My guess is that tagged private has no advantage over interface,
especially with a default implementation around Unbounded_String, which
doesn't need to be controlled, but then controlled extension would be
heavier. Then the choice between private and interface amounts to
whether or not it could be useful to use simultaneously several
implementations of String_Holder in the same project. I cannot think of
any project where it would be the case, so I would lean towards private,
but maybe I'm lacking imagination here.

Still under the same assumption, is the above specification sane, or am
I missing something? Query procedure is probably not absolutely
necessary, but I guess it can be occasionally useful to save a string
copy compared to To_String, and it seems to be a very small
implementation burden anyway.

Still under the same assumption, can it be useful to provide unary "+"
functions to tersely convert String_Holder to String, and maybe
vice-versa, or would it do more harm (obfuscation) than good?

And lastly, is there any trick to allow a String_Holder object or
similar to be pre-elaborable?


Thanks in advance for your insights,
Natasha



             reply	other threads:[~2011-12-18 12:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-18 12:34 Natasha Kerensikova [this message]
2011-12-18 16:48 ` String_Holder ? Brad Moore
2011-12-18 20:55 ` Jeffrey Carter
2011-12-18 23:08   ` Natasha Kerensikova
2011-12-19 12:14     ` Niklas Holsti
2011-12-19 11:12 ` Martin
2011-12-19 23:53 ` Randy Brukardt
2011-12-22  9:08   ` Natasha Kerensikova
2011-12-22 10:08     ` Niklas Holsti
2011-12-22 12:23       ` Simon Wright
2011-12-23  1:26       ` Randy Brukardt
2011-12-23  6:18         ` Jeffrey Carter
2011-12-22 11:40     ` AdaMagica
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox