Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: C++11 immutable string

github.com

Post reply on HN
Print view View original

1–7 of 7 posts

Show HN: C++11 immutable string

#1

Post by syvex »

I'm looking for feedback on this approach to an immutable string (istring). The idea is to provide a super fast immutable string that can be efficiently passed to lambdas as well as be 100% thread safe.

Another bonus is faster hashing. If a string literal is given to istring, then the hash is computed at compile time! Other strings will have their hashes cached for later use. The istring is designed more or less after the python string in this regard.

It should also consume less memory than std::string and perform faster in all other areas.

Show HN: C++11 immutable string
github.com

Re: Show HN: C++11 immutable string

#2

Post by thegeomaster »

Great job. I like it how peole are moving to and developing for C++11 as I think it's a huge step forward in the standard. The one cosmetic complaint I have is that the slicing syntax is not verbose enough for my taste. Also, what hash algo did you use? Asking just out of curiosity. I remember running a benchmark a long ago of different non-cryptographic hashes. The collision resistance was pretty consistent across all of them, but some were really slow and some were really fast, and that could directly affect the performance on hashtables and other structures that rely on hashes.

Re: Show HN: C++11 immutable string

#4

Post by nikbackm »

Nican wrote: post #3

Just as a note, on Java 7, developers opted for not having a single buffer backing multiple strings due to the backing references never been deleted. [1] [2] [1] http://stackoverflow.com/questions/16123446/java-7-string-su... [2] http://www.reddit.com/r/programming/comments/1qw73v/til_orac...

Probably more of an issue when all of your strings work(ed) like that, as opposed to here where you must explicitly opt-in to use immutable strings with shared buffers.

Re: Show HN: C++11 immutable string

#5

Post by syvex »

thegeomaster wrote: post #2

Great job. I like it how peole are moving to and developing for C++11 as I think it's a huge step forward in the standard. The one cosmetic complaint I have is that the slicing syntax is not verbose enough for my taste. Also, what hash algo did you use? Asking just out of curiosity. I remember running a benchmark a long ago of different non-cryptographic hashes. The collision resistance was pretty consistent across a…

The hash is FNV-1a, which should be faster that what you usually get in your standard library. It's also relatively easy to implement with constexpr so that you get those nice compile time hashes.

http://www.isthe.com/chongo/tech/comp/fnv/

Re: Show HN: C++11 immutable string

#6

Post by syvex »

thegeomaster wrote: post #2

Great job. I like it how peole are moving to and developing for C++11 as I think it's a huge step forward in the standard. The one cosmetic complaint I have is that the slicing syntax is not verbose enough for my taste. Also, what hash algo did you use? Asking just out of curiosity. I remember running a benchmark a long ago of different non-cryptographic hashes. The collision resistance was pretty consistent across a…

I can't say I'm 100% happy with the slicing notation. I played around with some other wacky things, but then settled on overloading operator() to get a concise syntax.

In principle, you use it similar to python--s(5,10) instead of s[5:10].

I would have maybe liked to end up with s[5,10], but the only way to overload operator[] like that is with a pair. Then you'd end up with s[{5,10}]. So I figured it would be best to stick with just s(5,10).

Re: Show HN: C++11 immutable string

#7

Post by thegeomaster »

syvex wrote: post #6
thegeomaster wrote: post #2

Great job. I like it how peole are moving to and developing for C++11 as I think it's a huge step forward in the standard. The one cosmetic complaint I have is that the slicing syntax is not verbose enough for my taste. Also, what hash algo did you use? Asking just out of curiosity. I remember running a benchmark a long ago of different non-cryptographic hashes. The collision resistance was pretty consistent across a…

I can't say I'm 100% happy with the slicing notation. I played around with some other wacky things, but then settled on overloading operator() to get a concise syntax. In principle, you use it similar to python--s(5,10) instead of s[5:10]. I would have maybe liked to end up with s[5,10], but the only way to overload operator[] like that is with a pair. Then you'd end up with s[{5,10}]. So I figured it would be best t…

Not relevant in this case, but you may find this interesting (assuming you haven't seen it already): https://github.com/klmr/named-operator.
Post reply on HN