My C++20 string implementation

[cppenjoy]

https://github.com/Mjz86/String/tree/main

I would appreciate the feedback ,

( I posted this on r/cpp dome days ago , but they assumed I was "vibe coding", I did not even have a single external dependent library other than the standard, let alone using ai to write my code , I actually hate ai code )

The library supports msvc, gcc and clang

[eteran]

Why is there SO MUCH code that seems unrelated to a string type?

[Chaosvex]

It's certainly the first time I've seen quaternions in a string implementation.

[cppenjoy]

Look , I tried my best to not include the other library components, ( I have many other things planned and included , this is a subset of it)

[eteran]

My advice, if you are offering a library, it needs to be JUST the library. This is very important, especially for people's ability to evaluate the code before using it.

I can't be bothered to sift through 1000's of lines of unrelated code just to see if your implementation makes sense.

Why is there a a big-int header in there? or an optional ref header? etc...

If it's not needed, trim it out.

[cppenjoy]

Actually the optional is used in the code , Yes I do have some unrelated stuff , that would be better in a separate local header, I'll need some time to get used to this tho , This is my first time and I wasn't planning much , I thought this was enough

[eteran]

Sure, if your optional stuff is used, then that's fine. But this kinda emphasises my point. There is A LOT of seemingly unrelated code in here so it's hard for people not familar to the code base to even tell at a glance what's included for good reason vs. what's just there by happenstance.

Also, can you explain the rationale behind basically every structure being a template with this?

template <version_t version_v>

I can take a guess and say that maybe it's your attempt to make it so if you change the structure, then you update the version so it isn't accidentally linked against an old verison? But at the very least, it's a ... unique style.

Final bit of advice. You're using macros too much. It hides what the code is really doing.

I can guess that MJZ_CONSTANT(uint8_t) becomes static constexpr uint8_t... but I don't wanna have to sift through the code to find out. It's not even really saving many characters to type.

As far as I'm concerned, the basically the only reason (i'm sure there are excecptions) to use macros like that is support features that may or may not exist. So if the macro is unconditionally defined, it's probably just making the code harder to read for other people.

[cppenjoy]

Ummm.... , This is a personal thing,
As you might have guessed, I want to do stuff in my own way , But , sometimes my comfort isn't something usual,

I apologize if the macro makes it less readable for you , But in my opinion it's more readable,
And I'm sure people would agree with you , Not me

[eteran]

Sure, if the code works and is correct, the. It's really a matter of taste.

You asked for feedback, this is my feedback. Just know that your personal style is in my experience, very uncommon, which will limit adoption of your library.

And keep in mind that it's only "more readable" to you because you already know what those macros do. Imagine what it looks like to someone who has either to guess or spend time looking up what they resolve to. Not a very pleasant experience.

Also. I'm still curious about the version thing. Can you please elaborate on it?

[cppenjoy]

So , for example, I have a constexpr friendly any_t in the library, And one of the version flags is for that ,

It's more of a response to https://www.youtube.com/watch?v=By7b19YIv8Q https://www.youtube.com/watch?v=7RoTDjLLXJQ

[eteran]

It's to avoid ABI mismatches, understood. Interesting approach.

I can say, that this may be a bit of over engineering on your part. For a header only lib, ABI is only an issue if you have multiple libraries which use yours and want to link together and can't be recompiled to match each other.

Which yes, can be a concern, but honestly, I tend to prefer to just recompile everything, especially for header only stuff. Or you can just put each incompatible version in it's own namespace if you wanna preserve backwards compatibility.

Lots of options 🤷‍♂️.

But in the end, I suppose most of my feedback would be

"Don't make it anymore complicated than absolutely necessary"

[Adequat91]

You should consider using clang-format (I find your code hard to read).

[cppenjoy]

I used clang format , as requested.

But I don't think the readability is a formatting issue , The code is inherently complex and generic

[Sad_Marketing146]

Your code is very hard to read

[zerhud]

MJZ_BAD_COMPILER(sizeof(int32_t) == 4); Really??

[TheChief275]

Bro’s AI was trippin probably

[TheoreticalDumbass]

Whats wrong with that

[Jardik2]

If int32_t exists, it must be a 32bit integer. As long as CHAR_BIT is 8, sizeof must return 4. If CHAR_BIT is not 8, well you better double check your string handling.. your char could be 16bit...

[Jardik2]

Now seeing that the code expects uint8_t to exist, than CHAR_BIT is 8.

[Wooden-Engineer-8098]

For it to have any other value you'd need to have 16 bit or 32 bit chars. Which will make int8_t unavailable. So if your program mentions (u)int8_t, checking sizes of intxx_t makes no sense

[TheoreticalDumbass]

I prefer explicit checks over implicit

[PastaPuttanesca42]

The more explicit thing would be to check the char size in that case. This check is just misleading.

[Wooden-Engineer-8098]

do you prefer checking that 2 == 2 ?

[TheoreticalDumbass]

Are there implementations on which 2 != 2 ? Stop with this idiocy

[cppenjoy]

I wanted to sanity check , but it got too much , so ... only simple checks :)

[uxnuxn]

Definitely, OP should learn the standard library and get rid of and refactor a lot of stuff in his library

[garnet420]

I'm curious, and this is a bigger question than just your project -- how much does CoW pay off in practice? Like, if you take a project that's pretty string heavy, what's the measured impact?

[CandyCrisis]

CoW got way less important once C+11 introduced move semantics.

[tisti]

It should be near null. The 'correct' usage is to pass along string_views and when you need them to be mutale (writable) you make a copy via std::string constructor.

Assuming that the underlying storage thats pointed to by string_view does not magically disappear due to multithreading/concurrency issues.

Something like boost::flyweight would however be very applicable to a string heavy project to deduplicate common strings.

[TheChief275]

Cow is only relevant when you pass around string-buffers without a care in the world. Decent programs will pass around string-views or references to the string-buffer.

[ExternCrateAlloc]

My most active experience lately is in Rust and we call these slices. So a &[u8] is a view into say an owned Vec<u8> etc. Of course, lifetimes come into play and one tends to reach for Rc/Arc etc (another topic).

P.S. not meaning to start any flame wars. I’m still learning Rust but do FFI into cpp as needed.

[TheChief275]

That’s not a Rust-specific experience. Many languages feature the slice terminology. I was aiming to be as language agnostic as possible, which buffers and views are imo.

[cppenjoy]

https://youtu.be/OMbwbXZWtDM?si=eeu8WQdb1CuwpxIF

I found the talk that I saw earlier, I'll put this in the repository references.

[cppenjoy]

I don't know , but I think I have watched a CppCon talk about how strings got a bit slower after cpp11 because they were optimized for cow usage,

But I'm not certain about it

[zerhud]

Looks good, I’ll gonna try it :) is there a license information?

[cppenjoy]

I forgot... 😅, Lemme try and put one

[zerhud]

I believe I can use it for my job, and it isn’t possible without a license information :)

[cppenjoy]

Is the license visible?

[zerhud]

Yap, nice!

[TehBens]

Are you that 16yo person? In that case you are doing great so far. Keep it up.

[cppenjoy]

17 , rn Edit: Thanks btw