Unbounded is said to be inefficient because it re-allocates."Efficiency" is only meaningful in the context of a project's quantitative timing requirements: an efficient implementation allows the project to meet those requirements, while an inefficient implementation does not.
In any case avoiding unbounded strings is almost certainly in the realm of premature optimisation
On 2021-12-02 19:17, Kevin Chadwick wrote:
Unbounded is said to be inefficient because it re-allocates.
In any case avoiding unbounded strings is almost certainly in the
realm of premature optimisation
In the absence of such context, any claims of "inefficiency" (and
especially blanket claims such as "Unbounded_String is inefficient")
simply demonstrate the speaker's incompetence.
In Go they have strings.Builder. I assume that is what Text_Buffer is
aimed to be. (Actually Go seems to have copied a lot from Ada such as
AWS API, unless they both are similar to something else like JAVA).
Is Text_Buffer usable today with GCC 11?
It is true only to a certain degree. When comparing algorithms it is valid to claim inefficiency without any context if computational complexity sufficiently
differs.
For example, an O(N) algorithm is unquestionably inefficient comparing to O(log
N) one. I leave marginal cases of very small N.
On 2021-12-02 21:15, Dmitry A. Kazakov wrote:
It is true only to a certain degree. When comparing algorithms it is
valid to claim inefficiency without any context if computational
complexity sufficiently differs.
For example, an O(N) algorithm is unquestionably inefficient comparing
to O(log N) one. I leave marginal cases of very small N.
This is false. If you have the O(N) algorithm and it meets your
requirements, then using it is more efficient than implementing the
O(log N) algorithm.
Unbounded_String is needed far less than many people think, but there
are application domains where it is much easier to achieve correctness
and clarity with a variable-length string abstraction than without.
Blanket statements about "efficiency" are dangerous for those working in
such domains.
And note, that in most cases it is really thoughtless as the choice is
made on the basis of how easy it is to declare a string component of a record type and then rewrite it.
Later on throughout the rest of the program the user of Unbounded_String will be consistently punished for that poor choice because normal string operations are very uncomfortable with Unbounded_String. But that
happens later. Right now and here, let us save a couple of code lines.
So the simplest and most persuasive blanket statement is OK to dissuade people from poor choices.
On 2021-12-02 21:15, Dmitry A. Kazakov wrote:
It is true only to a certain degree. When comparing algorithms it is
valid to claim inefficiency without any context if computational
complexity sufficiently differs.
For example, an O(N) algorithm is unquestionably inefficient comparing to
O(log N) one. I leave marginal cases of very small N.
This is false. If you have the O(N) algorithm and it meets your
requirements, then using it is more efficient than implementing the O(log
N) algorithm. If you have both and the O(N) algorithm meets your requirements, the effort to get your data into a form where you can apply
the O(log N) algorithm may still outweigh the time difference.
As for "very small N", I have worked on systems where linear search was efficient for sequences of 100,000 items.
In this thread bounded and unbounded get quite a bashing.standard library, if it is available?
"https://groups.google.com/g/comp.lang.ada/c/NINmFln-YS4/m/5De5DeUAAAAJ"
I thought bounded looked useful but then I realised that it allocates the max immediately anyway. It may be useful in constrained environments but then I do not use Strings in constrained environments.
Unbounded is said to be inefficient because it re-allocates.
In Go they have strings.Builder. I assume that is what Text_Buffer is aimed to be. (Actually Go seems to have copied a lot from Ada such as AWS API, unless they both are similar to something else like JAVA).
Is Text_Buffer usable today with GCC 11?
strings.Builder in Go behaves similarly to unbounded in that it doubles the allocation as required but it only returns a string when needed and does not have string operations. You can Grow the builder to avoid re-allocations.
"https://pkg.go.dev/strings#Builder"
If possible without breaking all of the string functions (length and separate capacity) and Unbounded Strings had a Grow function, then wouldn't that relieve the efficiency issue?
In any case avoiding unbounded strings is almost certainly in the realm of premature optimisation most of the alleged 10% of the time that it useful, but it would be nice to know of and use something akin to strings.Builder, preferably from the
On 2021-12-02 19:17, Kevin Chadwick wrote:
"Efficiency" is only meaningful in the context of a project's
Unbounded is said to be inefficient because it re-allocates.
In any case avoiding unbounded strings is almost certainly in the
realm of premature optimisation
quantitative timing requirements: an efficient implementation allows
the project to meet those requirements, while an inefficient
implementation does not.
In the absence of such context, any claims of "inefficiency" (and
especially blanket claims such as "Unbounded_String is inefficient")
simply demonstrate the speaker's incompetence.
For an example of context, a decade ago I worked on a soft-real-time
system that made extensive use of Unbounded_String and had no problem
meeting its timing requirements. Unbounded_String was clearly
efficient for that project. Since most projects that would use Unbounded_String have even less restrictive timing requirements than
that system, it seems likely that Unbounded_String will be efficient
for them, too.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 379 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:49:39 |
| Calls: | 8,141 |
| Calls today: | 4 |
| Files: | 13,085 |
| Messages: | 5,858,055 |