Just poking my head in and saw this.

y - added support for building on MacOS, finished OneString tests.

Moral of the story: If you don't know what it does, you can't just ignore it!

@jcmcdonald , it appears that Scott still has tests from OneString, and this code passes those 100% of the time. Are these tests still applicable?

Hey @jcmcdonald , would you mind taking a look at this? I'm willing to bet that I'll have to make more changes to the tests, but I want to know if I'm on the right path. The good news is that OneString appears to be functional. Tests are passing consistently, even under stress tests running them 1000 times.

• Draft 1 of OneString tests

Overall looks good. Code itself is sharp. OneString is out of date with my current version, not sure if that will be a problem. One wordiness change I would make for documentation (appears in two places).

Because Phabricator fixed the issue somehow, here is a screen shot of my terminal when I run the code:

Somehow the two appear to be the same in the copied version, but I *believe* there is an extra character in the second one that is messing with the parsing of the particular OneChar.

• Added documentation to header file, trying to work out error that is adding random characters

Fixed in rewrite by using double size code from FlexArray.

Fixed in rewrite.

Invalidated when we decided to rewrite OneString

• beginning to write tests for onestring

@jcmcdonald , this isn't fully tested or documented yet, but I've gotten the rewrite back up to speed with the original version.

• OneString rewrite is back to previous functionality

Need to add operators, swap and substring still.

Not ready for review, but contains my initial work on rewriting OneString.

@jcmcdonald , yes, I should have a new revision with my version soon.

One of the errors valgrind cites with the code has to do with a for loop in OneChar.

• Just pushing up so I can switch to my laptop

This was actually resolved in the process of removing OneStringBase.

This all looks great. Docs are especially sharp.

Operator>> existed, but resize problem was fixed by adding a resize function and sizing the input appropriately.

"Fixed" this by reallocating the master array, however this has seemed to cause a memory leak.

After doing some research, attempting to use a deleted object is classic undefined behavior. The functions works as expected if you comment out this line. Not a huge development, but the delete command is definitely the problem.

OneStringBase no longer exists, functionality is once again equal to before refactor.

The part of this task that was preventing "ul" from being added is completed.

Functions are rearranged and cleaned up (ordered by use and alphabetized), still have to clean up unused code segments.

Still have to clean up comments, but OneString.cpp is structured better now.

• cleaned up OneString

I believe the problem lies not within insert, but in double size.

As it turns out, there was no destructor implemented. This accounted for 90% of the leaks, but some still remain.

Not in a state to be reviewed. Code is still messy, there are quite a few behavior issues, and the code is still very leaky.

• Refactoring to combine OneString with OneStringBase

Most overload clashes are gone, still a couple of quickstring remnants remain, mainly in calls to double size. Still very broken.

Working through overload clashes, as well as removing remnants of quickstring.

To further detail the problem, when you try to insert to the end of a OneString, the correct number of letters will be added, but not the correct letters.

Appending letters to end of OneString not currently working.
Pretty sure the error causing a random letter to be added to the string is not within the scope of this task.

@jcmcdonald, is there any reason Scott designed this recursively? I don't fully understand the function, and it seems like this could be written simpler (albeit probably slower).

• Finally worked through lvalue error.

• Refactoring OneChar
• Onechar.cpp updated, trying to work though assignment operator issue

• Literals up and running, space bug still exists

• It doesn't segfault! But it also doesn't work :/

The line in question was not the problem, I ended up changing 149 of unit.cpp to if (ch == usCheck) and fixing an off by one error. This allowed the code to compile cleanly and run with zero memory issues.

• modified: docs/source/onestring/onestring.rst

@jcmcdonald , I thought that this may be the solution as well, but simply removing the line causes the program to fail to compile.

Looks good for the most part. Small, nitpicky question at line 259. Otherwise, good to go.

Perhaps I'm unclear on exactly what you mean.
If we want the graph of the size of the array over time to resemble ln(x), wouldn't we reach a point where memory allocation would actually delete memory instead of allocate it (input of the function is greater than output)?