Any performance reason to put attributes protected/private ?

views:

114

answers:

+1 Q:

Any performance reason to put attributes protected/private ?

I "learned" C++ at school, but there are several things I don't know, like where or what a compiler can optimize, seems I already know that inline and const can boost a little...

If performance is an important thing (gaming programming for example), does putting class attributes not public (private or protected) allow the compiler to make more optimized code ?

Because all my previous teacher were saying was it's more "secure" or "prevent not wanted or authorized class access/behavior", but in the end, I'm wonder if putting attributes not public can limit the scope and thus fasten things.

I don't criticize my teachers (should I), but the programming class I was in wasn't very advanced...

+3 A:

No. Making members private or protected is not going to provide any performance benefits; of course, the benefits to your design (information hiding) are huge.

Martin B 2010-06-29 11:47:10

I don't get, what kind of benefit is that ? For other people who will read my code ? Because for me, if I know what I'm programming, I really don't see any benefit, and I don't understand what makes its design so hugely better.

gokoon 2010-06-29 12:52:33

@gokoon: For a discussion of the benefits of information hiding, see Wikipedia for example: http://en.wikipedia.org/wiki/Information_hiding IH is beneficial even if you're programming by yourself, since it makes it easier to reason about the behaviour of your classes: If it's private, only the class itself could have changed it -- if it's public, it could have been changed from literally anywhere. This gets more and more important as the size of your project increases.

Martin B 2010-06-29 13:12:44

@gokoon: Information hiding is great because of when you need to make changes. Say that you have 100,000 lines of code and you want to change how Database::connect() is implemented. You can change and modify all the private data and functions in the Database class and you will never need to look at how the callers of Database::connect() use it.

Zan Lynx 2010-06-29 23:54:58

+1 A:

The teachers were right to tell you to use private and protected to hide implementation and to teach you about information hiding instead of propsing questionable performance optimizations. Try to think of an appropriate design first and of performance second, in 99% of the cases this will be the better choice (even in performance critical scenarios). Performance bottlenecks can appear in a lot of unpredicted cases and are much easier to come by if your design is sound.

To directly answer your question however: any reduction in scope may help the compiler to do certain optimizations, form the top of my head I can not think of any however right now in regards to making members private.

inflagranti 2010-06-29 11:49:45

I would not say they were right to teach that using `protected` hide implementation... simply because it does not. Exposing a datum to a derived class is equivalent to making it `public`. `protected` is only worth for some methods.

Matthieu M. 2010-06-29 12:35:57

Of course you can always inherit from a certain class just to gain access to it's protected fields (which I assume is what you mean by protected does not hide implementation). But thats like arguing that the const modifier in C++ does not make values const, as you can always const_cast a value and modify it at will.

inflagranti 2010-06-29 12:48:18

C++ access controls have been described as "protection against Murphy, not Machiavelli". They document their intent and usually prevent accidental violations, but won't stop determined misuse.

Mike Seymour 2010-06-29 18:17:13

+3 A:

There's no such thing as public, private and protected once your code is compiled, so it cannot affect performance.

There's also no such thing as const in machine code (except perhaps ROM), but the compiler can make some logical optimisations to your program by knowing whether a value can change (in some situations).

inline rarely has any effect. It is merely a suggestion to the compiler, which the compiler is free to ignore (and often does). The compiler will inline functions as it sees fit.

Peter Alexander 2010-06-29 11:51:32

"in some situations" = virtually never, since a const variable can be aliased, and this is very difficult to prove the contrary.

Alexandre C. 2010-06-29 12:12:10

If you had `const int a=1, b=2; int c=a+b;` the `a+b` expression would be evaluated at compile time. I agree that it is rare, but it does happen often enough to be aware of.

Peter Alexander 2010-06-29 12:17:40

@Alexandre: modifying a constant object gives undefined behaviour, so the compiler doesn't need to prove it can't be modified.

Mike Seymour 2010-06-29 12:20:52

"There's also no such thing as `const` in machine code" - maybe not, but on most platforms, literals and constant objects at namespace scope will end up in a read-only memory region, which will trap any attempty to modify them.

Mike Seymour 2010-06-29 12:27:03

You contradict yourself. You say that there are no access modifiers in compiled code, hence they cannot affect performance, but then go on to say that there is no const in compiled code neither, but her the compiler can optimize. The first statement is of course wrong, as that in the compiled code there is no any type information left, nevertheless the compiler can make a huge number of optimizations thanks to the type information available at compile time.

inflagranti 2010-06-29 12:54:21

@inflagranti, `const` is not an access modifier, it is a cv-qualification.

Peter Alexander 2010-06-29 20:54:04

@Peter Alexander: I never said it was. My point is that neither const nor private/protected are there in the compiled code, but first you argue that hence one cannot use them for optimizations and then you say the exact oposite.

inflagranti 2010-06-30 06:23:58

ansaurus

tags:

views:

answers:

Any performance reason to put attributes protected/private ?

related questions