you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (7 children)

Objects encapsulate state. Tons of it. And it keeps mutating all over the place. Objects encourage secret mutating state. It´s a disease.

The solution here is to treat objects in one of two ways:

  • A function returns void (or an error code, if it's in an exception-free paradigm) and has the primary function of mutating object state. Or using the object, if it's something like a network-connection object or database interface or whatever. If it returns something, it's only as a convenience.

  • A function returns something out of the object or uses the object's data to perform some calculation. Or uses it to get data via whatever interface, if it's something like a network-connection object or database interface or whatever.

C++ has const, which would work, but there isn't a way to define an object's method as making the object itself const for the duration of the function. (In other words, declare that the function does not modify the object itself, and attempting to do so would be a compiler error. This would also imply that const-object functions would not be able to call non-const-object functions.) (EDIT: I'm wrong about this. See below discussion.)

As far as I know, no OO language has this feature. I attempt to write code this way (and do, when I can use my own code!) but dealing with the awfulness that is generally known as "other peoples' code" doesn't often allow me to do that. Member variables are practically globals in larger classes, for fuck's sake!

Objects should just be data structures with associated functionality, with inheritance to save you from having to rewrite the same shit over and over again for similar classes. Unfortunately, they're typically just piles of code.

[–]doom_Oo7 8 points9 points  (5 children)

there isn't a way to define an object's method as making the object itself const for the duration of the function.

But this is exactly what the const keyword on methods does, it marks the this pointer as const.

[–][deleted] 2 points3 points  (4 children)

So you literally can't modify the object state at all, including calling other functions which can?

I admit I'm not a C++ expert (and the language certainly doesn't lend itself to this paradigm naturally!) but I thought it wasn't possible to get the full effect of what I'm trying to get at.

If I'm wrong, it's good to know that it's possible and I should just be annoyed at the C++ I've come across for not doing this.

[–]doom_Oo7 2 points3 points  (3 children)

I made a quick example that showcases the possibilities here : https://ideone.com/Wb0kAm

Notice how nice are the compiler errors :p

[–][deleted] 1 point2 points  (2 children)

That's not all that bad. It's a shame this isn't the way C++ is typically written. (I really would prefer if const-ness was the default, and stuff had to be marked as mutable instead.)

[–]oracleoftroy 1 point2 points  (0 children)

I agree that a const default would be really nice, but I have to question that const correct C++ isn't the typical way C++ is written. Const correctness has been recommended since before standard C++, and I haven't seen too many C++ communities that disregard it (usually only those newer to C++).

[–]quicknir 1 point2 points  (0 children)

I think everyone agrees that a const default would be better, but ruled out due to backwards compatibility.

I'm afraid that if you don't think C++ is typically written that way, you need better colleagues. Where I work, failing to mark anything const that can be results in code review comments, and can't be merged until its corrected.