Attached: 8AE5DAB6-C3F5-4530-9146-CFDBA9523EE4.png (940x347, 29.46K)
Explain yourselves, C++ chuds
Angel Gutierrez
Juan Rodriguez
I dont remember what sending a parameter to string does as you did (,3) so I cannot explain myself
Joshua Torres
and? is there an explanation for this rather odd behavior? what's going on here?
Austin Lopez
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
Cameron Wright
Wow that's retarded.
Jaxon Ward
Yeah, I wrapped the literal in std::string and the results are identical. Ok, that’s retarded to me
Aiden Ross
top kek. who even comes up with this madness?
Liam Long
it's powerful, git gud scrub
Gabriel Williams
That's pretty bad
Joshua Russell
It's powerful bugs and backdoors waiting to happen.
This is shit I'd expect from javascript or php, not C++.
Ian Hall
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.
Grayson Carter
>filtered by entry level c++ type system concepts
again, get gud scrub. std::string can be mutable, const char pointers cant be.
Alexander Perez
welcome to shitty constructors, type promotion rules and wide variety of other absolutely brain damaged sepples garbage. enjoy your stay.
Brandon Martin
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;
}
Parker Ortiz
Both are used as strings, also there are dynamically allocated const char* all over many code bases. The fact that is different is retarded.
Ethan Miller
Yes it's terrible and no one likes it.
Nicholas Sullivan
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.
Sebastian White
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.
Ethan Myers
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.
Bentley Miller
>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.
Ryder Jenkins
Though with Rust he will have to deal with str, String, OsString, OsStringExt and who the fuck knows what else.
Nathan Garcia
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.
Brody Sanders
Rather have many types that have clear operations, that one that has many unclear.
Dominic Harris
>entry level
Holy shit, the coping is real.
Jeremiah Turner
>to prevent ambiguity they should make them act the same.
bro you okay?
Luis Howard
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