Explain yourselves, C++ chuds

Attached: 8AE5DAB6-C3F5-4530-9146-CFDBA9523EE4.png (940x347, 29.46K)

I dont remember what sending a parameter to string does as you did (,3) so I cannot explain myself

and? is there an explanation for this rather odd behavior? what's going on here?

Two different constructors.
s1 copies first 3 characters form buffer because you pass in char*
s2 is substring from index 3 to end because you pass in std::string

Wow that's retarded.

Yeah, I wrapped the literal in std::string and the results are identical. Ok, that’s retarded to me

top kek. who even comes up with this madness?

it's powerful, git gud scrub

That's pretty bad

It's powerful bugs and backdoors waiting to happen.
This is shit I'd expect from javascript or php, not C++.

std::string is a proper c++ class, the other is a pointer to read only section of the compilation unit. they are not the same. it is desirable to have them behave distinctly to prevent ambiguity.

>filtered by entry level c++ type system concepts
again, get gud scrub. std::string can be mutable, const char pointers cant be.

welcome to shitty constructors, type promotion rules and wide variety of other absolutely brain damaged sepples garbage. enjoy your stay.

try not being gay

#include
#include
#include

int main() {
const char* str = "Not Gay C++";
char* s1 = strdup(str);
s1[3] = '\0';

printf("%s\n", s1); // Not
free(s1);
return 0;
}

Both are used as strings, also there are dynamically allocated const char* all over many code bases. The fact that is different is retarded.

Yes it's terrible and no one likes it.

or he can just learn Rust and not worry about any of this shit unless he needs a job, which he'll know how to do since Rust will teach him all the knowledge he'd need to deal with braindamage like this.

no kid, they are not both dynamically allocated, one is a static ready only piece of memory, the other makes an owned copy of said read only piece of memory such that it can be modified (if you omitted const on the type of sts::string). get gud scrub.

It's not desirable for (char *, size_type) to behave differently from (std::string, size_type).
To prevent ambiguity they should behave similarly, or one or both of them should fail to compile. But successfully doing different things is a recipe for mistakes.

>dangerous behavior even at basic levels
>hurr durr git gud, because I can't defend it
The problem here is with the automatic "autoboxing" conversion of the char* to string in the first declaration. This is high level language type "let me think for you" shit they've implemented. A type shouldn't be automatically converted at one spot, but not at another. That's JS level retardation. You can hurr durr all you want.

Though with Rust he will have to deal with str, String, OsString, OsStringExt and who the fuck knows what else.

true, using a braindead language like rust is a perfect match for this braindead entry level learner, if you want them to be permanently retarded. guess that is why microsoft and amazon love rust so much, keeps people stupid.

Rather have many types that have clear operations, that one that has many unclear.

>entry level
Holy shit, the coping is real.

>to prevent ambiguity they should make them act the same.
bro you okay?

In this example, but it's not like the constructor knows whether a const char * points to a statically or dynamically allocated string.

It is especially bad in this case because const char* can automatically be converted to std::string.

$ cat faggot.cc
#include
#include

static void fuck_you(const std::string &s)
{
std::cout