well those are called c++ pure programmers
like they derive the CObject class in MFC and stuff
besides you can "hack" the private easily
did it once in VC

and another thing is that using methods for setting a variable
is just for "beautiy" of the OO part

hmm besides C++ is actually SLOWER that c
(just if you use the class becuase of the virtual tables etc)

Arkon
[QSoft Systems]

quote:

---

Original post by Zeblar Nagrim
Some C++ guys use only class members and declare most of them private and think they code in a super object-orientated way. I think that is ridiculous and slow down your tempo. Let say u have a int variabel called x in a class. Why should I make it private and change it with two member functions (commonly called get/set something) instead of declaring it public?

---

1) You may not want the programmer to be able to set variable x, only retrieve the value.

2) Only allows the user of the class to access the interface of the class, and not the class innards. This keeps your class black boxed (ie, totally seperate) from other code. This way you can change the implementation of the class without creating compile errors in programs that use the class (ie, you can change the variable x to variable y and not have to change code in 100 files that use that variable). The is simple code reusing 101.

3) Detailed variable/function naming and comments also "slow down your tempo", but that doesn't mean they are bad.

4) You can make those get/set functions inline so you get back that 0.0000001 fps you lost by making function accessors.

quote:

---

Original post by Arkon
well those are called c++ pure programmers
like they derive the CObject class in MFC and stuff

---

Uh, I sure as heck don't use MFC for game programming. I DO use it for Windows programming but I sure don't think that MFC is an elegant use of object oriented programming. It just happens to be much faster to work with compared to straight Win32, when speed isn't a major concern.

You should really watch those gross generalizations. Doesn't give you much credibility.

quote:

---

Original post by Arkon
besides you can "hack" the private easily
did it once in VC

---

As far as I'm concerned "hack" em if you'd like. Making the variable private isn't supposed to make it impossible for the programmer to get to the variable. You can "hack" local variables in C, so does that mean you should use all global variables?

Making variables private are for reasons I've already stated above. If a programmer wants to get direct access to them that badly, then I say go for it.

quote:

---

Original post by Arkon
and another thing is that using methods for setting a variable
is just for "beautiy" of the OO part

---

Yes, it is.

quote:

---

Original post by Arkon
hmm besides C++ is actually SLOWER that c
(just if you use the class becuase of the virtual tables etc)

---

C++ is NOT slower then C in any way whatsoever! Please try to understand the difference between C++ and object oriented programming, and how/when C++ CAN be slower before you make such ridiculous generaliztions such as this.

First of all, using C++ does not mean you use classes. And using classes does not mean you use virtual functions. And using virtual function does not mean you need to access the virtual table dynamically. It would only need to do so when the instance of a class wasn't allocated on the heap. If it was, then any compiler worth a damn would compile away the vt.

And even when you do use virtual function on the stack and need to access the vt, the speed loss is negligible. Tons of games have been written in C++ using object oriented techniques, Unreal and AOK coming to mind off hand, to prove that point.


- Houdini

Edited by - Houdini on June 4, 2001 10:11:41 AM

i didn't say how slower it becomes
i just says it BECOMES SLOWER
doesn't even matter if it becomes slower in 0.0000004 seconds
it still slower!
that's why i said when using virtual functions!

and i hack the private member for educational purposes only
however, the CObject was just example of pure oo programmers!
programming games in MFC code be really ugly!

Arkon
[QSoft Systems]

Edited by - Arkon on June 4, 2001 10:55:08 AM

quote:

---

Original post by Oluseyi

Say you declare your variable in file1.cpp and wish to use it in file2.cpp without worrying about headers and "ownership disputes", simply declare the variable (again) in file2.cpp as extern.

---

extern int variable; // this variable is owned by another file

Thats exactly what I have been doing except the variables aren''t in a class/function, they are just out on thier own. Is it possible to do that inside a function?

I thought doing that was making a global variable.

quote:

---

Original post by Oluseyi

Say you declare your variable in file1.cpp and wish to use it in file2.cpp without worrying about headers and "ownership disputes", simply declare the variable (again) in file2.cpp as extern.

---

extern int variable; // this variable is owned by another file

Thats exactly what I have been doing except the variables aren''t in a class/function, they are just out on thier own. Is it possible to do that inside a function?

I thought doing that was making a global variable.

quote:

---

Original post by Oluseyi

Say you declare your variable in file1.cpp and wish to use it in file2.cpp without worrying about headers and "ownership disputes", simply declare the variable (again) in file2.cpp as extern.

---

extern int variable; // this variable is owned by another file

Thats exactly what I have been doing except the variables aren''t in a class/function, they are just out on thier own. Is it possible to do that inside a function?

I thought doing that was making a global variable.

Sorry about that. Stupid IE gave me an error and I didn''t realize it posted so I tried to post it again (I feel like a real idoit).

quote:

---

Original post by Arkon
i didn''t say how slower it becomes
i just says it BECOMES SLOWER
doesn''t even matter if it becomes slower in 0.0000004 seconds

---

Curious then. Since calling functions also makes the program slower, even negligibly so, do you steer away from them as well?

I only ask because it sounded like you were stating the "slowdown" as a reason you stick with procedural programming.

quote:

---

Original post by Arkon
hmm besides C++ is actually SLOWER that c
(just if you use the class becuase of the virtual tables etc)

---

True you did add "becuase of the virtual tables" but it still isn''t an issue of C++ vs C. You can do object oriented programming using virtual tables in C as well, you just have to write the code yourself.

In retrospect, your original statement looks like you did understand the difference, but too many people don''t and I wanted make sure it was pointed out that it has nothing to do with C++ or C.

Also, as I stated in my previous post, using virtual tables does not necessarily make your code slower. It only does if you are using virtual functions AND the class is instantiated on the stack. If it''s on the heap any good compiler will take out the virtual table.

quote:

---

the CObject was just example of pure oo programmers!
programming games in MFC code be really ugly!

---

Yes, but it''s an example of a bad (imo) object oriented library. I could just as easily write a bad procedural library and say that it''s an example of pure c programmers. It means nothing.


- Houdini

quote:

---

Original post by Arkon

well those are called c++ pure programmers
like they derive the CObject class in MFC and stuff
besides you can "hack" the private easily
did it once in VC

---

lets put it this way:

Trigger locks on guns (private members of classes) prevent you from accidentally blowing your foot off.

there is nothing stopping you from intentionally removing the trigger lock, aiming at your foot and firing.

===============================================
It''s either ether or the other,
I press my window to the glass,
the glass turns to gas...
I''m going upstairs now, to turn my mind off...
to turn my mind off...

There''s an interesting article on the C/C++ Users Journal web site thats relevant to some of the last posts in this thread. You''ll find it here: http://www.cuj.com/experts/1902/hyslop.htm?topic=experts.
For those of you that are too lazy to read it: The author(s?) wrote a program that accessed a class member in three different ways: Inline accessor, ''outline'' accessor and direct access( public data member ). The funny thing is: With all optimizations turned on the program with inline accessors turn out to be on average slightly faster than the equivalent program that uses direct access.
Weird, huh? I downloaded the program and tried it myself with gcc/cygwin. I got the same results.