Way to make SharedArray over fixed length Strings?



if you do SharedArray{AbstractString}(10, 1)

you get the following error:

ERROR: ArgumentError: type of SharedArray elements must be bits types, got AbstractString

Is there a package for making fixed length strings to allow their use in SharedArrays?


edit: is there a way to make it work with LegacyStrings.jl?


What about an SVector{N, Char} from StaticArrays.jl?

julia> using StaticArrays

julia> isbits(SVector{10, Char})


How do you treat that as a string though?

And is there a way to do build in rpad()'ing?

julia> s = SVector{4,Char}(b"abcd")
4-element SVector{4,Char}:

julia> convert(String, s)

As for padding, just fill the remaining characters with spaces?


Might be nice to have a package implementing a fixed-length SString{n,T} <: AbstractString type on top of SVector{n,T} (supporting both T = Char for UTF-32 and T = UInt8 for ASCII). If you don’t need to support strings containing NUL, then you could also use NUL-padding to give a string of length ≤ n with fixed-length storage.


Can you guys take a look at this package I wrote up?

It’s probably more of a proof of concept than an efficient design at this point.

// I basically just started with @stevengj’s LatexStrings.jl and worked my way backward


There is also: https://github.com/JuliaComputing/FixedSizeStrings.jl


Well damn… Can anyone discuss the pros & cons of the two implementations?

I’m cool with letting the package I wrote die, I just want to know it’s for the right reasons.


Well, yours doesn’t really seem to be optimized for performance since you don’t properly propagate the fixed size.
Also, this is a pretty crazy use of parse and eval:

You do realize, that you can just do SVector{length(string), UInt8}(Vector{UInt8}(string)) ? :slight_smile:

In general, I always found it useful to have a fixed size string, that looks more like this:

struct FString{N}
data::NTuple{N, UInt8}

So that one can have a Vector{FString{32}} with variable sized strings - which seems to be a shortcoming of FixedSizeStrings.

I made a prototype for such a type for my GPU blog post: fixed_strings.jl

All packages don’t support UTF8, so a package that would offer that would be nice.

In general, I recommend to just extend the existing package with more functionality - especially when both packages are still that small!


I wholeheartedly agree with this. There was just no way to find your code?

It seems like you only came forward because of Cunningham’s Law:

“The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.”

What do you think the best route is moving forward?

I just don’t really like writing pointless code and wasting time.

// and from ANN: HigherPrecision and Pruning and quality control for the package ecosystem, it seems like this kind of thing is happening all the time to Julians :frowning:


There was just no way to find your code?

Sorry :wink:
I meant extending FixedSizeStrings, which isn’t my package. I should probably contribute my code to that package as well :slight_smile:


you could figure out whats missing for your use case in FixedSizeStrings and make a PR - feel free to ping me for guidance :slight_smile: i should also figure out what i could add…