[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: ISO_C++_Logo.svg.png (25 KB, 500x563)
25 KB PNG
>discover that shallow copying is actually useful
>rebrands it as "move semantics"
Does Sepples really?
>>
>>108707272
Well sometimes it copies and sometimes it moves, hence "semantics". Moving all the time isn't possible and even if it were, you may not wish to do it.
>>
std::move() is just static_cast<T &&>(). uses different overloads, hence the "semantic".
>>
>>108707291
>look, this poorly solves a self-inflicted problem!
>>
>>108707323
i agree completely. if you thought l and r value references were tricky wait until you discover the "universal reference" and references collapsing. all of this to avoid copying pointers.
#include <iostream>

void f(int &v)
{
std::cout << "f: lvalue" << "\n";
}

void f(int &&v)
{
std::cout << "f: rvalue" << "\n";
}

template <typename T>
void perfect_forward(T &&v)
{
if constexpr (std::is_same_v<int &, decltype(v)>)
std::cout << "forward: lvalue\n";
else if constexpr (std::is_same_v<int &&, decltype(v)>)
std::cout << "forward: rvalue\n";
if constexpr (std::is_same_v<int, T>)
std::cout << "T: int\n";
else if constexpr (std::is_same_v<int &, T>)
std::cout << "T: int &\n";
f(std::forward<T>(v));
}

int main()
{
int i = 10;
perfect_forward(i);
std::cout << "\n";
perfect_forward(10);
}
>>
>>108707272
move semantics is not a shallow copy
>>
>>108707398
here is another fun one because i am bored. what do u think will happen? it may not be obvious. a non templated function that accepts an r value reference as an argument can only be called if that r value is an expiring value.
#include <iostream>

void f(int &v)
{
std::cout << "f: lvalue" << "\n";
}

void f(int &&v)
{
std::cout << "f: rvalue" << "\n";
}

int main()
{
int &&a = 10;
int &b = a;
std::cout << "a is a(n) ";
if constexpr (std::is_same_v<int &&, decltype(a)>)
std::cout << "rvalue";
else if constexpr (std::is_same_v<int &, decltype(a)>)
std::cout << "lvalue";
else if constexpr (std::is_same_v<int, decltype(a)>)
std::cout << "regular";
std::cout << "\nb is a(n) ";
if constexpr (std::is_same_v<int &&, decltype(b)>)
std::cout << "rvalue";
else if constexpr (std::is_same_v<int &, decltype(b)>)
std::cout << "lvalue";
else if constexpr (std::is_same_v<int, decltype(b)>)
std::cout << "regular";
std::cout << "\n";
f(a);
f(b);
}
>>
>>108707272
move semantics gives very clear ownership and lifetimes, which is nice, but like everything else in c++ "the committee" went with the most unclear and overly generic implementation possible.
>>
>>108707398
Fucking amazing.
>>
>>108707452
99% of the time, it is.
>>
>>108707556
except for the part where the moved-from object no longer points to the same underlying data
cpp is really not that difficult to critique, yet morons still find new ways to fail even at that
>>
>>108707668
>the moved-from object
Literally who cares about that, it's supposed to go away soon.
>>
>>108707466
>int &&a
I've been out of the Sepples loop for a while, what does this even do?
>>
>>108707556
100% of the time, it's not.
>>
>>108707272
You say it like language support was necessary for it at all
>>
>>108707853
t. committee member
>>
>>108707874
Bjarne clearly thought so, otherwise C++11 would have never existed.
>>
>>108707789
Please, save your sanity and flee.
>>
>>108707882
I think he just feels obligated to keep adding stuff to keep his job, and was too creatively bankrupt to add something useful.
>>
>>108707789
>be 15 years behind
what were you in for? did you kill somebody?
>>
>>108707781
The object the data has been moved into. It would be nice if all of the data it now owns didn't get fucked up by the dtor of the moved-from object
>>
the only reason to learn this arcane bullshit is for a job. otherwise just learn rust or c.
>>
>>108708088
>dtor
C doesn't have this problem.
>>
>>108708224
No company worth working for will ever demand you know all the gotchas in C++.
>>
>>108707668
This. Case in point op failing miserably to cite "trivial move/copy" semantics, thinking "movability" is the same thing as a shallow copy
>>
>>108708546
leave him alone, anon. he got filtered and needs to vent on /g/.
>>
>>108707789
it lets you initialize a reference variable with a prvalue without making it const. that's it. it's still an lvalue reference.
>>
>>108708532
It does. Programming is logic and logic is universal. Just because the language itself can't express a transfer of ownership in it's semantics and has you put it in a comment doesn't make you immune to cleaning up data you no longer own.
>>
>>108707781
then its not a shallow copy
>>
>>108708722
>logic is universal
"no."
>>
>>108708722
No other language forces meme shit on you such as rule of 3/5/0. Get lost.
>>
>>108708538
And no company tells you what subset of C++ features you should be familiar with. And most don't even have a defined subset other than vibes.
>>
>>108708792
Righty-o. It's a shallow copy plus some extra bullshit to prevent destructors, which are automatically called for your convenience, from fucking shit up.
>>
>>108709011
i still don't know why the "assignment operator" even fucking exists
>>
>>108708555
C++ is a filter, but not in the way you think.
>>
>>108709022
Showing off operator overloading probably, like cout << "nigger".

In C, assignment really means "copy". For scalar types, the semantics are obvious.

For structs, it performs a memberwise copy, recursively (a surprising number of people don't know this and copy structs with memcpy instead). Of course, if the struct contains pointers or handles to resources, the copy will be "shallow": for a "deep" copy, you'll need a custom function.

For some bizarre reason, C++ came up with the perverse convention that copies must be "deep" by default, and the assignment operator should be overloaded to reflect this. It turns out, this is not always what you want, hence move semantics.
>>
>>108709103
Noone is forcing you to deep copy on assignment.
>>
>>108707272
I don't get it. You can just use fucking pointer.
>>
>>108707272
>Shallow copy owning pointers
>Copied object deletes them
>Original object UAFs
Just stop posting it you don't know what you're talking about
>>
>>108707287
>Moving all the time isn't possible and even if it were, you may not wish to do it.
*blocks your path*
>>
>>108710562
>Move is always memcpy, no other definition allowed
This is a bad thing
>>
>>108708592
>initialize a reference variable with a prvalue without making it const
Statement dreamed up by the utterly Deranged
>>
>>108710568
It's not. Rust can express C++ style moves with a simple method. C++ can't express Rust moves in any way.
This is why RAII will always come with an overhead in C++.
>>
>>108710580
>C++ can't express Rust moves in any way.
It's the default move you get under rule of 0.
>>
>>108708592
Genuine question: what concrete, language-agnostic problem could this feature solve?
>>
>>108710744
a noncopyable nonmovable nontemplate aggregate initialized no constructors wrapper class with a nonunion, nonvariant nonpointer reference data member... oh in function scope? uh none.
>>
>>108708592
that is not entirely true. it is actually a different type than an lvalue reference, but behaves identically.
#include <iostream>

int main()
{
int a = 10;
int &&r = 10;
int &l = a;
if constexpr (!std::is_same_v<decltype(r), decltype(l)>)
std::cout << "not the same\n";
}


>>108709022
its so u can do something like this. as you may see i am making a deep copy of the data. in c when u do '=' on a struct the struct itself is copied, and does not allow reallocation or any other desired outcome.
#include <cstring>
#include <iostream>

class C
{
private:
int *mem_ = nullptr;
int size_ = 0;

public:
C(int size) : size_(size)
{
mem_ = new int[size];
}

C() = default;

~C()
{
if (mem_)
delete[] mem_;
}

C &operator=(const C &other)
{
if (this == &other)
return *this;
if (mem_)
delete[] mem_;
size_ = other.size_;
mem_ = new int[size_];
std::memcpy(mem_, other.mem_, size_ * sizeof(int));
return *this;
}

void fill()
{
for (int i = 0; i < size_; i++)
mem_[i] = i;
}

void print()
{
std::cout << mem_ << "\n";
for (int i = 0; i < size_; i++)
std::cout << mem_[i] << " ";
std::cout << "\n";
}
};

int main()
{
C c1(10);
C c2;
c1.fill();
c2 = c1;
c1.print();
c2.print();
}
>>
>>108711194
okay, why does it need to be distinct from the constructors?
>>
>>108710597
>It's the default move you get under rule of 0.
Yeah, but moves for objects with no destructor have no benefits whatsoever in the first place.
When moves shine is with stuff that actually own some resource. And if it owns some resource, then it must have a destructor. And if it has a destructor and supports moves, then it needs a special moved-out state which adds overhead and breaks invariants.
Rust has no such issue because it actually supports destructive moves.
>>
>>108710744
None, it's just a workaround because C++ was never supposed to support anything like that.
>>
>>108711272
>Yeah, but moves for objects with no destructor have no benefits whatsoever in the first place.
yes it does, because it means the optimizer has more surface area to elide the intermediate object
variables are not memory cells, references are not pointers
repeat after me
variables are not memory cells.
references are not pointers.
>>
>>108708801
Yes
>>108709011
Neither does C++, they're just shorthands to represent how you would represent certain data properties using C++ semantics, and they are optional. Nobody is stopping you from doing it C way and eg. doing the rule of 3 by implementing a freestanding deallocation function for your data structure plus a freestanding deep copy function for it.
>>
>>108711288
There is no reason for why compiler shouldn't be able to figure it out for trivially movable objects like this even if you don't use moves explicitly, just copy assigns.
>>
>>108708224
>rust
never ever
>>
>>108711302
these days sure
when the feature was put in? not really. now it's trapped in there lol
>>
>>108711316
nah, it's happening.
>>
>>108711264
it is not a constructor is an operator... without overloading the '=' operator it behaves like c.
// compile with '-fno-strict-aliasing'
#include <iostream>

struct S
{
int *ptr_;
int a_;
S(int *ptr, int a) : ptr_(ptr), a_(a)
{
}
S() = default;
};

void print(S *s)
{
unsigned char *ptr = (unsigned char *)s;
const int size = sizeof(s);
for (int i = 0; i < size; i++)
{
auto x = ptr[i];
for (int i = 7; i >= 0; --i)
std::cout << ((x >> i) & 1);
std::cout << "\n";
}
std::cout << "\n";
}

int main()
{
int i = 10;
S s1(&i, 20);
S s2;
print(&s1);
print(&s2);
s2 = s1;
print(&s1);
print(&s2);
}
>>
>>108709103
>For some bizarre reason, C++ came up with the perverse convention that copies must be "deep" by default
That's because C++ mostly deals with classes that own their data outright, so if class A contains class B that owns some memory address, to get a valid copy of A it needs a valid copy B and B doesn't have any mechanism that would allow two of them to share data. Such as wrapping them in a shared_ptr
Something like Rust's Cow would be lower overhead but without BC it is so incredibly easy to end up with an invalid reference practically nobody in C++ uses such a pattern
>>
>>108709022
Because copy and move ctors exist (horrible idea) and assignment operator is a built-in way to express the same thing on an already existing object
>>
>>108711328
Rust will remain a tranny meme language
>>
>>108711264
if you only had one way to copy then you need some bullshit like
bool is_initialized
to decide if you need to do memory allocations before you copy data in. You see, we are not like C, we are C++.
>>
>>108710744
Minimizing copies.
>>
>>108711194
>that is not entirely true. it is actually a different type than an lvalue reference, but behaves identically.
actually it is entirely true. the language makes it perfectly clear. that's why I said it's an lvalue reference, which it is, and i didn't say it's an int& -- "a reference to an int", which it's not.
>>
>>108711264
So you can do it on already existing objects.
>>
File: 1657065688710.jpg (44 KB, 500x500)
44 KB JPG
I'll never understand how low iq this board is to not be able to handle C++. I'm a black guy who grew up in the ghetto and I learned c++ fine. I accepted its rules, and chose what I needed for the job. Meanwhile, I come to this board that is suppose to be filled with smart people, and instead I get autistic crybabies that get flustered when they see they have to do something more than important a library to do all the work for them in python.
>>
>>108711450
my mistake you are correct. i blame the committee for giving me brain damage and forgetting how to read.
>>
>>108711517
its okay I forgot some people call int& and int&& lvalue and rvalue references too, which i guess is not wrong? but it's way too confusing so I never ever do that, just stick to int-ref and int-ref-ref as types and lvalue and rvalue as value categories. yes we can just blame the comittee for this whole misundersanding.
>>
non-destructive move is retarded
all your objects are now implicitly optionals
>>
>>108712363
>non-destructive move is retarded
std::swap
>>
>>108711316
Read the thread and tell me again why not. Reminder rust has real moves and doesn't have these insane value categories.
>>
>>108712672
>Read the thread and tell me again why not.
Rust is gay and will never be a real programming language.
>>
>>108712730
Funny you never addressed anything/g/ related in your reply. You sound like a nocoder.
>>
>>108712766
Im a six figure programmer who has used every language. And Rust is the gayest.
>>
>>108712807
Ok, nocoder.
>>
>>108711319
The feature was put in because they wanted move semantics. But they could figure out destructive moves so they settled on the second best thing. Well, "best" in context of C++.
>>
>>108712363
Sepples 36 will fix it
>>
>>108708722
>cleaning up data you no longer own
that's your problem right there.
>>
>>108711289
>they're just shorthands to represent how you would represent certain data properties using C++ semantics, and they are optional. Nobody is stopping you from doing it C way and eg. doing the rule of 3 by implementing a freestanding deallocation function for your data structure plus a freestanding deep copy function for it.
No other language forces this much meme shit on you, listen to yourself for one second.
>>
>>108711443
There are a gazillion ways to do that already without this arcane shit.
>>
>>108711486
Nobody can truly understand C++. If you believe otherwise, you are either a liar or low IQ yourself.
>>
>>108710562
Implementing that in C++ would break existing codebases. That may be acceptable for a toy language like Rust, but C++ handles sensitive infrastructure and needs to uphold backwards compatibility.
>>
>>108714796
>C++ handles sensitive infrastructure and needs to uphold backwards compatibility.
So does COBOL.
>>
>>108714545
I've got bad news, once you actually graduate from fizzbuzzing you will need to manage resources
>>
>>108714689
Again, you're not forced to do shit. People do it because it is genuinely more convinient to wtite a destructor once and having it called automatically for free instead of writing a destroy method and having to call it yourself every fucking time
>>
>>108714916
so...oop (or at least c++ version of it) doesn't doesn't do a good job in exactly the metric
>manage resources
in which it claims to be better than c?

if that's not your point, i don't know what your point is.
>>
>>108714950
Destructors are better than anything C has. To this day, ctards invent new and exciting nonstandard extensions just to do basic bitch cleanup.
>>
>>108714950
define
>doesn't doesn't do a good job
My point is that just like other nanon said, you are a moron
>>
>>108714960
>Destructors are better than anything C has.
Except handling failures.
>>
>>108714689
Other than Rust, there basically isn't a language that has more than a thousand users that does what C++ does as well. It was a meme language gone too far, but boomers loved OOP slop and you have to adapt to it. If you don't, use Rust. That's it.
>>
>>108714960
>better
for trivial cases, sure.
but when the burden of the non-trivial cases start accumulating, it gets to the point where the bottom line isn't vert convincing.

and c++ value categories are a burden

>>108714962
see above.
>>
>>108714972
>there basically isn't a language that has more than a thousand users that does what C++ does as well.
One thing is always true: where you can use C++, you can use C. In particular, if someone gave you C++ interfaces, a thin layer of wrappers will hide them. Using C instead of C++ has several practical benefits: faster development cycle, reduced complexity, better support by tools such as debuggers, higher portability and interoperability. When C++ is an option, C is probably a better option.

Another thing is always true: where you can use a managed environment (where the behavior of wrong programs is defined), using it will save a lot of trouble. C++ (like C) is designed for unmanaged environments (where the behavior of wrong programs is undefined). Unmanaged environments make it very hard to locate faults and impose no limit on the damage done by an undetected fault. In theory, C++ implementations can run in managed environments, but in practice they don't because of innumerable compatibility issues.
>>
>>108714972
Having fallable destruction is a lot less important than making sure function exit is properly handled. How many goto fails do you have? Ya, fuck off.
>>
File: vagueposting.jpg (53 KB, 320x326)
53 KB JPG
>>108714976
So
>doesn't doesn't do a good job
means
>when (...) non-trivial cases start accumulating, it (...) isn't vert convincing
This tells me fucking nothing. You defined "I think it's not good" as "I think it's not good (when it gets complex"
>>
>>108714981
There is literally nothing wrong with goto fail.
>>
>>108715092
There is literally everything wrong with goto fail you absolute fucking retard.
>>
>>108715100
Elaborate. The burden of proof is on (You).
>>
>>108714796
There is nothing backwards incompatible to add support for destructive moves, aka trivially relocatable types as C++ people call them. There are proposals running around, it was even supposed to be on C++26, but they removed it because committee can never agree on anything like that kek.
>>
>>108715123
I already explained it. You faggots still can't figure out how to implement defer and have papers and nonstandard cleanup annotations flying around. It's obvious to anyone who isn't a dumb nigger why gotos to a cleanup routine is pure shit, especially since CVEs have been literally caused by improper cleanup, or a lack thereof or even a complete bypass of security functionality.

Fuck you and kill yourself.
>>
>>108715708
And not a single argument as to why it's bad was provided. Figures!

>You faggots still can't figure out how to implement defer and have papers and nonstandard cleanup annotations flying around.
There is literally no need for any of that shit. goto cleanup just works. Million-line projects which billions of people rely on daily use it without much trouble. Only nocoders and dumb academics demand defer or other meme features.

>hurr hurr hurr
>>
>>108714785
What's so fucking hard about using a programming language? You guys see you have to do stuff more manually in C++ and lose your fucking minds.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.