Earlier quoted context omitted.
They maybe should be better called *Kemper Strings" then?
Probably. Or just SSO, as it is basically a very well known name already.
Why German Strings Are Everywhere?
51–58 of 58 posts
Re: Why German Strings Are Everywhere?
#52Earlier quoted context omitted.
I knew the C++ strings were optimized so. I do not like calling them "German". First time I see them called so (I know it, you can search yourself, as SSO -short string opt.), and looks as some kind of nationalist pride thing to me. Is certainly not a unique or new idea, many scheme/lisps implementations do that for strings AND numbers. Downvotes coming from other connationals :) love you! I know… never say anything…
According to TFA, the name was coined by Andy Pavlo, who did his undergrad in New York, Doctorate in Rhode Island, and now teaches in Pittsburgh. I see no indication that he is German. [edit] Lecture slide with the term is also linked from TFA: https://15721.courses.cs.cmu.edu/spring2024/slides/05-execut...
Re: Why German Strings Are Everywhere?
#53Re: Why German Strings Are Everywhere?
#54Earlier quoted context omitted.
What do you like to call Hungarian notation?
I don’t know any other name for it. While this strings are basically SSO (or a twist of it).
Re: Why German Strings Are Everywhere?
#55Earlier quoted context omitted.
I don’t know any other name for it. While this strings are basically SSO (or a twist of it).
From TFA and AndyP's slides it seems to specifically refer to a variant of SSO where, for large strings, a fixed-sized prefix of the string is stored along-side the pointer, in the same location as that fixed-size prefix would be fore SSO strings. This means that strings lacking a common prefix can be quickly compared without pointer-chasing (or even knowing if they are small vs large).
basically SSO (or a twist of it)
Re: Why German Strings Are Everywhere?
#56Earlier quoted context omitted.
> It's not anything special? That's just `string_view` (C++17) Just because something already exists in some language doesn't make it less clever. It's not very widespread, and it's very powerful when applicable. This format can handle "string views" with the same logic as "normal strings" without relying on interfaces or inheritance overhead. it's clever.
> It's not very widespread It is tho? > and it's very powerful when applicable. I don't believe I stated or even hinted otherwise? > This format can handle "string views" with the same logic as "normal strings" without relying on interfaces or inheritance overhead. "owned" and "borrowed" strings have different lifecycles and if you can't differentiate them easily it's very easy to misuse a borrowed string into an UAF…
You're getting into pedantics about specific languages and their implementation. I never made a statement about C++ or java. I work in primarily in c99 myself.
> the utility of making them implicit is close to nil. > Without relying on interfaces or inheritance.
Implement a function that takes three strings without 3! permutations of that function either explicitly or implicitly created.
Re: Why German Strings Are Everywhere?
#57In case anyone wonders why they are called German strings: the article mentions the "research predecessor" of Cedar, Umbra. Umbra is a project of TU (technical university) Munich, Germany.
They maybe should be better called *Kemper Strings" then?
Re: Why German Strings Are Everywhere?
#58Earlier quoted context omitted.
> It's not very widespread It is tho? > and it's very powerful when applicable. I don't believe I stated or even hinted otherwise? > This format can handle "string views" with the same logic as "normal strings" without relying on interfaces or inheritance overhead. "owned" and "borrowed" strings have different lifecycles and if you can't differentiate them easily it's very easy to misuse a borrowed string into an UAF…
> "owned" and "borrowed" > java 1.4's You're getting into pedantics about specific languages and their implementation. I never made a statement about C++ or java. I work in primarily in c99 myself. > the utility of making them implicit is close to nil. > Without relying on interfaces or inheritance. Implement a function that takes three strings without 3! permutations of that function either explicitly or implicitly…
No, I'm using terms which clearly express what I'm talking about, and referring to actual historical experience with these concerns.
> Implement a function that takes three strings without 3! permutations of that function either explicitly or implicitly created.
In the overwhelming majority of cases this is a nonsensical requirement, if the function can take 3 borrowed strings you just implement a single function which takes 3 borrowed strings.
In the (rare) situation where optimising for maybe-owned makes sense, you use a wrapper type over "owned or borrowed". Which still needs no "interface or inheritance".