Lightning Talk: But I was doing the right thing! - Andrei Zissu - CppCon 2025

本站添加: 2026-05-31

[00:00:00]Being at CPPCON has been amazing because you can directly speak with the experts.

[00:00:04]I've had conversations with Bjarn Strus with Sean [music] Parent and they're all very friendly and accessible and willing to give their opinions or advice on C++ again. So uh yesterday I told you a funny story completely unrelated to C++.

[00:00:35]Today I have two uh horror stories which as all good horror stories go they must be of course related to C++ uh for my from my recent work history [clears throat] and the common ground between them is that in both cases we did what is apparently the right thing to do probably indeed is. [snorts] So I really like making things const when possible especially member uh data.

[00:01:04]Uh there's uh I've read blogs about this being problematic sometimes can because you can't move uh objects which have uh con uh members but I wasn't too worried about that because what's the worst that can happen the worst case it will be informed it won't compile you'll drop the const and move over with your life.

[00:01:25]Uh so we can see here an example of a class which um a we have a move only strct into which we're embedding a um non-const member and we move the uh outer class. It moves together with it the inner member. We can see the move constructor being invoked. No problem.

[00:01:48]Now let's make this the member const. As I said what's the worst that can happen?

[00:01:54]Oi and did you see what just uh changed there?

[00:02:01]Okay. So if you look closely at the output, we have the copy constructor now being invoked and this code is perfectly wellformed.

[00:02:11]So it turns out when you move a class which contains a const member the synthesized move constructor or assignment whatever is going to uh [clears throat] add the amperand amperand. So in this case it would it will happily create a constar value and of course uh the constar value will not bind to any move constructor of C.

[00:02:37]it will copy C even though the outer class strct is being uh moved. Big issue this C could have been some huge vector and this would not be what we were expecting to get.

[00:02:51]Uh so from here the takeaway uh that we've reached from now at work is that con data members in general not allowed unless the outer class is uh as I call it non-transferable both non-compable and nonmovable. I'm relaxing this rule in cases where it's mainly primitive types which I don't really care if they are copied or moved. Second story again everything being done just right. Uh we had a function of of course this is greatly simplified a function which is looking for some uh string inside the windows uh uh data structures and it's supposed to return the uh value of the string if it finds it. If it doesn't find it returns a null ptr perfectly legitimate return returning by char pointer. This of course works. There's absolutely no issue here. We did the right thing. And now we get to this. We needed to uh put it in a turnary if together with another function that returns a stood string. And all of a sudden we are in deep trouble because in a turnary if the return type is the common type of two uh types in the combined condition. And now if we are calling the first function returns a null ptr that null ptr would will be used to construct a stood string which is always a great guarantee of a fun day when you try to construct a sto string from a null ptr.

[00:04:22]Uh so here the takeaway unless someone comes up with a better idea is to not return the conchar pointer if it may um return legitimately an alpr otherwise things like this might just happen.

[00:04:40]Thank you.

[00:04:42][applause]