Remove unused/broken references to util_dynamic_array.h

[johnmcfarlane]

I assume that external sources of util_dynamic_array.h still exist. If not, I'm happy to remove the preprocessor macro related to this also.

[johnmcfarlane]

Suggestion: to help make the Git history more readable, I recommend rebasing changes on the main branch before merging them.

[ckormanyos]

Hi @johnmcfarlane what I did was pull util::dynamic_array into the header file uintwide_t. And the uintwide_t class needs util::dynamic_array for very large digit counts.

If the project has an external source of util::dynamic_array, then WIDE_INTEGER_DISABLE_IMPLEMENT_UTIL_DYNAMIC_ARRAY should be defined and the header uintwide_t will not implement its own copy of util::dynamic_array.

[ckormanyos]

So your change is fine for the CMake build, but the proprocessor maccro needs to remain. Personally, i'm not very happy with the way i use util::dynamic_array and wish that C++ would offer such a fixed-size array class with dynamic, one-shot, fixed-width allocation. Maybe there is such a container by now, but I personally am not aware of it.

[johnmcfarlane]

@ckormanyos yes there are many nearly-the-same containers and proposals for many of them. However vector covers so much area that the are not super-urgent.

Have you considered vector? I know it's larger than {pointer, size} but if you were to implement an elastic number which is growing exponentially (e.g. many successive calls to n *= 42;), then this would involve fewer dynamic allocations.

Alternatively, does unique_ptr<T[]> help in any way?

[ckormanyos]

Have you considered vector? I know it's larger than {pointer, size} ...

Yes John, this is actually a long story.

Believe it or not, in fact, some of the systems that I originally used (and one system I still use today) with uintwide_t do not have STL implementations --- so no std::vector available either. So I opted to write a custom container as well as a bunch of easy-to-write other STL stuff like array, etc. With these methods, all my projects and samples --- even for the most tiny microcontrollers --- work fine.

In cnl, I might recommend to eventually kick out the self-written container (or switch it for a replacement enabled/disabled via preprocessor option) and go with a constant-sized kind of a std::vector. When doing this sort of thing, I usually end up wrapping std::vector with a templated Size parameter.

The code using the container should be container independent. What we ultimately do in cnl is not yet known to me. But at least I got the whole story out there.

[johnmcfarlane]

Got it. Then can I suggest the adaptor pattern as used by std::queue where you pass the container type into the number type as a template parameter?

I would recommend you split up the type into two types - roughly along the lines of P1889's bounded and unbounded types. Here's an example of how you might go about this without duplicating too much code.

[ckormanyos]

... recommend you split up the type into two types - roughly along the lines of P1889's bounded and unbounded types. Here's an example of how you might go about this without duplicating too much code.

Hi @johnmcfarlane I am confused how/if there is a template parameter for is_signed/is_unsigned? Is that the parameter S in the P1889? What is the type of S if it even is sign-related? I had expected something like template parameter bool is_unsigned = false.

[johnmcfarlane]

Please see separate issue for latest CE prototype. It has a bool parameter. It's up to you if that's the most appropriate interface. I'd say it's a good fit of you firmly believe that a sequence of unsigned limbs is the best representation by a fair distance. Because then how do you know if the ripper is signed otherwise?

[johnmcfarlane]

Here's the thread with the example: #91 (comment)