Comment On Safety Critical Encapsulation

Okay, he actually removed the sentence : "your company name here".

Wow!

Premature optimization for teh fail!

This reminds me of back in college when someone was trying to understand the concept behind private/protected functions. After a series of explanations about protecting your information so others couldn't see it the student thought for a second and asked, "What if they go in and change your code?".

The teacher didn't really know how to respond to such a stupid question.

Cyrus:

This reminds me of back in college when someone was trying to understand the concept behind private/protected functions. After a series of explanations about protecting your information so others couldn't see it the student thought for a second and asked, "What if they go in and change your code?".

The teacher didn't really know how to respond to such a stupid question.

What was stupid (and downright wrong) was not the student's question but the teacher's explanation.

private and protected have NOTHING to do with "protecting your information so that others can't see it". It's NOT a security feature. It's a design feature. The point is to declare which parts of a class are implementation details that can change at any time and which clients of the class should therefore not rely on.

That's why we used to have this beauty in our code:

    LicenceManager.INTERNAL_USERS++;

This question is not stupid - explaining "private/protected functions" with "information security" modell is stupid. It produces wtf-programmers that think "if i declare variable as private then data will be secure from crackers". "public interface, private guts" modell ist better

Hmmm someone use a replace all "x"-es into "-"s. Is that the WTF?

The "inde-es" part is funny.

I wonder if it was done by Alex, Vlad or Vlad's predecessor.



Note from Alex: FWIW, only changes I made to the submission was formatting (removing a linebreak here and there, etc) and adding the "----" ...

I like how all the items in the comment are numbered -- 1.0, 2.0, and so on. It's like a whole Word document inside a comment block.

And what are inde-es?

Why bother with private methods when you can hide all your information by changing it to hyphens?

Roger:

This question is not stupid - explaining "private/protected functions" with "information security" modell is stupid. It produces wtf-programmers that think "if i declare variable as private then data will be secure from crackers". "public interface, private guts" modell ist better

AOL. And it should be a good time to explain something about /social contract/ between developers (and between yourself and the instance of yourself a few weeks ago).

By the way, modern frameworks like Spring destroy all this public/protected information hiding anyway.

- jon

Besides allowing for changes to the way data is handled internally by the class, it also helps to ensure that other programmers using the class use it correctly, by letting you control how changes are made to internal variables, and how these variables are represented to other parts of the program, which in turn makes the class easier to use and reduces the need for documentation.

It also makes for more robust classes. For instance, you might decide that the "dimensions" property of a bitmap object is undefined if the bitmap doesn't (yet) contain data that has width and height, and then, rather than returning meaningless data to the caller, you might want to generate an exception.

In OOP public variables are just generally a bad idea. And with an optimizing compiler you most likely wouldn't gain any speed from using them anyway.

Jon haugsand:

By the way, modern frameworks like Spring destroy all this public/protected information hiding anyway.

Hi, I don't know Spring, but I see a lot of fuss about it. Your comment intrigued me. What do you mean when you say that Spring destroys information hiding? Would you please care to elaborate? Thanks!

Captcha: bathe - not saturday yet though

X-lib had the exact-same-comment in all of its ("C") data structures: this field is private, so you should not change it - and people didn't, because if they did, X became unstable and inevitably crashed.

I find it interesting that the more you attempt to hide something, the more people seek it out and try to access it just to see what happens.

The real WTF is that the hyphens under 1.0 Identification are six, but the hyphens under 3.0 Description are only four.

snoofle:

X-lib had the exact-same-comment in all of its ("C") data structures: this field is private, so you should not change it - and people didn't, because if they did, X became unstable and inevitably crashed.

Those were programmers of the old school.

Cyrus:

the student thought for a second and asked, "What if they go in and change your code?".

I've seen that before:

#define protected public

#include "some/header.h"

#define protected protected

Scary stuff..

The idea behind “information hiding” – i.e. encapsulating certain methods and properties to users of a class – is a fair idea in theory, but in practice, it’s just too slow. Think about it. If a “public” method just ends up calling some “private” method, that’s just a waste of a call. And if a lot of calls are made to that public method, then that’s a whole lot of wasted calls!

It's people like you who perpetuate bad coding practices by writing things like this.

Encapsulation has been proven to be a useful feature, especially in complex programs, or in teams consisting of several members working on individual modules.

Shame on you for stating that it causes overhead and is a waste!

So scary

captcha: craaazy

Did nobody else notice the "Unclassified" in the header block? This gem appears to have been done on US Government money (probably by a contractor). That is awesome.

Phylyp:

The idea behind “information hiding” – i.e. encapsulating certain methods and properties to users of a class – is a fair idea in theory, but in practice, it’s just too slow. Think about it. If a “public” method just ends up calling some “private” method, that’s just a waste of a call. And if a lot of calls are made to that public method, then that’s a whole lot of wasted calls!

It's people like you who perpetuate bad coding practices by writing things like this.

Encapsulation has been proven to be a useful feature, especially in complex programs, or in teams consisting of several members working on individual modules.

Shame on you for stating that it causes overhead and is a waste!

Damn! Nice troll! 5/5!

Phylyp:

It's people like you who perpetuate bad coding practices by writing things like this.

It's called satire.

captcha: pirates - Can't argue with that!

Let's assume for a second that this is C++ and this class defines absolutely no inline functions at all. Then a function like this:

int the_class::get_some_int() const

{

    return this->some_int;

}

actually ends up being a push on the stack, which can add up to lots of overhead just accessing a single integer. In Java or C# the runtime usually sees those trivial calls and inlines them, but when that code is separated into a .cpp file it's compiled and executed as a normal function, thus leading to lots of indirection. I worked at a place once which strictly forbade using inline functions (those functions defined in the header) and the performance noticeably suffered because of it. The real WTF was why the management, who understood nothing about programming, forced this upon us. They claimed that it safely hid the implementation details. They had no idea that the .h files weren't shipped with the final build of the software.

Once again, the writer of WTF is wrong. There's nothing slow about properties (well in .NET anyways). Perhaps s/he should think before s/he speaks and realize that slow is a meaningless term unless it's a comparative. Even then, we need benchmarks and statistics. In .NET, you won't find almost any difference... they are both insanely fast racing C++ fields (oh yes... .NET is no RAD system; it rivals C++, not Java).

Patrick:

I worked at a place once which strictly forbade using inline functions (those functions defined in the header) and the performance noticeably suffered because of it. The real WTF was why the management, who understood nothing about programming, forced this upon us. They claimed that it safely hid the implementation details. They had no idea that the .h files weren't shipped with the final build of the software.

That's actually not a WTF. The point is that it makes it possible (with some clever coding admittedly) to evolve the implementation of the interface without changing the ABI of the library. If you're inlining stuff in the interfaces, that goes out of the window. (Note, it's much much easier to do this with C code than with C++ code.)

John Coleman:

Once again, the writer of WTF is wrong. There's nothing slow about properties (well in .NET anyways). Perhaps s/he should think before s/he speaks and realize that slow is a meaningless term unless it's a comparative. Even then, we need benchmarks and statistics. In .NET, you won't find almost any difference... they are both insanely fast racing C++ fields (oh yes... .NET is no RAD system; it rivals C++, not Java).

You really should get that sarcasm detector fixed. In the posted WTF a developer makes his class variables public for the sake of speedy access, and appeals to users not to modify them directly. Is it so difficult to realize that Alex is speaking from the point of view of the WTF author?

I've always thought that private/protected/public thing was less than useful. If you have a class that is useful and well-written, chances are its implementation never changes. and any change to the class usually involves a re-write to the entire structure anyway, because seldom is the implemenation/interface as clear-cut as everyone wishes.

Has anyone EVER actually changed the private implementation of a class, and not have to re-work all the stuff dependent on it? Or are my suspicions correct and this is something that lots of thought goes into for little-to-no long-term benefit?

I've seen that before:


#define protected public

#include "some/header.h"

#define protected protected

Scary stuff..

Holy hell. I haven't used C/C++ in years and years, but please tell me that isn't legal!

Seems reasonable...

John Coleman:

Once again, the writer of WTF is wrong. There's nothing slow about properties (well in .NET anyways). Perhaps s/he should think before s/he speaks and realize that slow is a meaningless term unless it's a comparative. Even then, we need benchmarks and statistics. In .NET, you won't find almost any difference... they are both insanely fast racing C++ fields (oh yes... .NET is no RAD system; it rivals C++, not Java).

So hey, on the internet, there's this thing called satire. But please, tell me more about your deep knowledge of C++/.NET/Java benchmarking, I do enjoy some good e-dick waving.

That's entirely legal because the language parser knows nothing about it, seeing as it's done entirely via preprocessor macros.

m:

Has anyone EVER actually changed the private implementation of a class, and not have to re-work all the stuff dependent on it? Or are my suspicions correct and this is something that lots of thought goes into for little-to-no long-term benefit?

If you actually provide a good interface and clearly defined purpose for your classes, then it's pretty common to change the implementation without touching the public interface.

If you just write random methods as you need them and label them public or private, not so much.

Scared:

Holy hell. I haven't used C/C++ in years and years, but please tell me that isn't legal!

It's perfectly legal (why wouldn't it be?) but it won't always work... "class" declarations start with an implicit "private" that wouldn't be changed unless explicitly declared.

Now this makes me understand why some people suggest putting private stuff first (without the private keyword). So only private things are well protected.

Though it seems to me that you can also access private members and methods through pointers. All you need to know is the type and the name.

When he said "Fast Performance" he was referring to time to write the code and not time for the code to execute.

Patrick:

Let's assume for a second that this is C++ and this class defines absolutely no inline functions at all. Then a function like this: [omitted] actually ends up being a push on the stack

Which is why you don't write it that way; you declare it inline, and it turns into the same code that direct access would have generated. The whole point of the information hiding exercise is to save work in the future. For example, if it turns out that you need to lock a mutex before you read the value, you can add that to the accessor, rebuild, and everyone's happy. If you can't afford the code bloat caused by inlining that extra mutex code (read: if you're designing for an embedded system that doesn't have enough flash), you can change the function to non-inline at that point and rebuild, and pay the speed penalty only when you must.

Patrick:

I worked at a place once which strictly forbade using inline functions (those functions defined in the header) and the performance noticeably suffered because of it. The real WTF was why the management, who understood nothing about programming, forced this upon us. They claimed that it safely hid the implementation details. They had no idea that the .h files weren't shipped with the final build of the software.

Now that is a real WTF. I have to wonder what got screwed up in the past to motivate the PHBs to implement a rule like that.

Patrick:

Let's assume for a second that this is C++ and this class defines absolutely no inline functions at all. Then a function like this:

int the_class::get_some_int() const

{

    return this->some_int;

}

actually ends up being a push on the stack, which can add up to lots of overhead just accessing a single integer. In Java or C# the runtime usually sees those trivial calls and inlines them, but when that code is separated into a .cpp file it's compiled and executed as a normal function, thus leading to lots of indirection. I worked at a place once which strictly forbade using inline functions (those functions defined in the header) and the performance noticeably suffered because of it. The real WTF was why the management, who understood nothing about programming, forced this upon us. They claimed that it safely hid the implementation details. They had no idea that the .h files weren't shipped with the final build of the software.

Java has no problems with aggressive inlining, even if the code is inside another JAR. It has to do with JIT compiling, and runtime optimization (in this case runtime inlining). I'm no expert on compilers, but I think I know that much.

The same could be done for .NET, but I don't know about .NET runtime optimization in the current .NET runtime environment.

C++ is another beast. I'd guess it's not really possible in raw C++, unless you start using template libraries which allows aggressive optimization (inlining, processor spanning,...) but only at compile time.

CAPTCHA: stinky, that was a funny one :)

dkf:

Patrick:

I worked at a place once which strictly forbade using inline functions (those functions defined in the header) and the performance noticeably suffered because of it. The real WTF was why the management, who understood nothing about programming, forced this upon us. They claimed that it safely hid the implementation details. They had no idea that the .h files weren't shipped with the final build of the software.

That's actually not a WTF. The point is that it makes it possible (with some clever coding admittedly) to evolve the implementation of the interface without changing the ABI of the library. If you're inlining stuff in the interfaces, that goes out of the window. (Note, it's much much easier to do this with C code than with C++ code.)

Note that some C++ compilers translate to C before compiling (Comeau C++ does that IIRC).

CAPTCH: Seems like captcha's are a fixed set...hmmm

Salami:

When he said "Fast Performance" he was referring to time to write the code and not time for the code to execute.

He certainly was not referring to the time taken from other programmers to write code using his class.

It's always faster to understand a class that has all its unneeded methods and fields set private.

So, um. I don't get what's so bad about this.

Sometimes accessor functions really _are_ too slow. In that case making the fields public and asking the callers not to modify them seems completely reasonable to me.

m:

I've always thought that private/protected/public thing was less than useful. If you have a class that is useful and well-written, chances are its implementation never changes. and any change to the class usually involves a re-write to the entire structure anyway, because seldom is the implemenation/interface as clear-cut as everyone wishes.

Has anyone EVER actually changed the private implementation of a class, and not have to re-work all the stuff dependent on it? Or are my suspicions correct and this is something that lots of thought goes into for little-to-no long-term benefit?

Yes. That's the whole point of public interface vs private implementation. The use of an object remains the same (ie interface doesn't change) but its inner implementation does (ie new data access layer). Only when the way you handle your object changes, does your interface change and as such the code where you manipulate these objects.

And,

Your suspicions are incorrect.

CAPTCHA: By all means...

Scared:

I've seen that before:


#define protected public

#include "some/header.h"

#define protected protected

Scary stuff..

Holy hell. I haven't used C/C++ in years and years, but please tell me that isn't legal!

You bet it is legal :). Can't say it's a good practice though ;-)

mikecd:

Scared:

Holy hell. I haven't used C/C++ in years and years, but please tell me that isn't legal!

It's perfectly legal (why wouldn't it be?) but it won't always work... "class" declarations start with an implicit "private" that wouldn't be changed unless explicitly declared.

There is a C++ idiom that counters these bad practices, pimpl!

CAPTCHA: how's my e-dick ;-)

mikecd:

Scared:

Holy hell. I haven't used C/C++ in years and years, but please tell me that isn't legal!

It's perfectly legal (why wouldn't it be?) but it won't always work... "class" declarations start with an implicit "private" that wouldn't be changed unless explicitly declared.

Perhaps it is legal, but a much more clean code would be achieved with:

#define protected public

#include "stuff"

#undef protected

And it will always work, since protected is never the default.

On the second thought, you can easily defend against the evil haxx0rs, by putting #undef protected (and probably #undef private) in all your headers.

If there was a CAPTCHA, it would be: craazy (or maybe scaary).

Phylyp:

Shame on you for stating that it causes overhead and is a waste!

Shame on you for walking around with a broken irony detector.

Patrick:

They claimed that it safely hid the implementation details.

// Rect.cxx -> Brillant!



int Rect::GetWidth() const {

// They will never figure out that we just

  return m_width;

// Arr harr harr harr harr!!!

}

mikecd:

It's perfectly legal

Except it's not. 17.4.3.1.1/2 of the C++ standard WD reads:

"A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords."

m:

I've always thought that private/protected/public thing was less than useful. If you have a class that is useful and well-written, chances are its implementation never changes. and any change to the class usually involves a re-write to the entire structure anyway, because seldom is the implemenation/interface as clear-cut as everyone wishes.

Has anyone EVER actually changed the private implementation of a class, and not have to re-work all the stuff dependent on it? Or are my suspicions correct and this is something that lots of thought goes into for little-to-no long-term benefit?

I sure hope this is a joke. I've made dramatic changes to the implementation almost without changing the interface numerous times (ORM -> new database, internal caching etc.). I guess you don't need it in a throw-away code that lives less than an year.

ObThisIsNotAlwaysAWTF.

Suppose I've got a language that doesn't support friend syntax.

Suppose I have a getter that acutally does something more interesting than return the variable (think, oh say lazy loaded resources).

So (pseudo-code)

private Butt butt;

public Butt getButt() {
if (butt == null) {
butt = new Butt(shit);
}
return butt;
}

and because it's a multithreaded app I need to wrap that getButt in a mutex.

Now if I'm in a tight loop that has to call getButt on a lot of classes, that could be expensive. If I know damn well all those butts are all nice and shitty to begin with, I can use the private butt variable safely, so I make butt public, but a comment in the code that says "don't even think of using this if you don't know what you are doing" and hope noone actually does. (I might make a public inlined function called getButtIfYouReallyKnowItIsSafe() or something silly, but that's still a public function that really shouldn't be being called.)

This kind of stuff happens when you need to optimize the hell out of a very small loop. Not all public functions are trivial getters and setters of private data variables.

It's not legal because the C++ Standard says that you can't #define a keyword to be something else. It will work on most compilers though.

http://www.gotw.ca/gotw/076.htm

AdT:

mikecd:

It's perfectly legal

Except it's not. 17.4.3.1.1/2 of the C++ standard WD reads:

"A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords."

Well, since it's in the standard library chapter, it looks like it only applies to standard headers. That way, if your file does not include any standard headers, you can redefine protected, no? (Evil, evil, new realms of evil... ;-))

Encapsulation is just convention. Some perfectly OO languages don't enforce it at all. Having used one for ten years, making the compiler act as a half-assed encapsulation police officer seems silly to me now. The programmer provided a perfectly good convention in place of the enforced convention provided by C++. Is anyone here really going to take the position that C++ is the one true way, and anything else is dumb? This ain't 1990...