C / C++ / MFC

raja jamwal31-Dec-09 8:47

raja jamwal

31-Dec-09 8:47

Well you can use getcurrentdirectory to get the directory where the application was executed only if the parent process haven't changed that.

Bram van Kampen3-Jan-10 23:48

3-Jan-10 23:48

raja jamwal wrote:
Well you can use getcurrentdirectory to get the directory where the application was executed only if the parent process haven't changed that.

No, Not Realy. getcurrentdirectory does exactly what it says. That is not nescessarily the same dir as where the exe is located.

That's why I use GetModuleFileName();
Smile | :)

Bram van Kampen

raja jamwal9-Jan-10 4:06

raja jamwal

9-Jan-10 4:06

yeah i know, the current directory variable attached with the module can be changed.

Bram van Kampen9-Jan-10 16:10

good encapsulation technique ? [modified]

9-Jan-10 16:10

Amen

Bram van Kampen

doug2526-Dec-09 10:03

26-Dec-09 10:03

EDIT:

The solution to my problem is to declare certain member variables as protected and use get and set functions to work with them. The reason I was reluctant to do this was because I thought it would be better to be able to read from protected variables directly but the speed difference compared to using a function to read a variable is no different, or so minute that it will never affect performance in any way. This is the standard for working with encapsulated variables so it's definately better than what I was doing before and allows for proper encapsulation.

I've decided to scrap the code below, what I thought was a good solution, because it's poor style and few people would understand exactly the point of it if they were to attempt to edit code that uses it :

//#define EDITINGCODE

#ifdef EDITINGCODE
	#define PROTECTED protected
#else
	#define PROTECTED public
#endif

// Using PROTECTED allows the declaration of
// member variables that shouldn't be modified
// without using member functions
// while they can be read from
// within any scope

class Class1
{
PROTECTED:
	int var;
};

Quite often I only want to change member variables of classes using member functions and prevent these from being changed elsewhere in a program but still allow access to the variables data.

A common programming technique for this effect is to have a get function in a class that returns the value of a private / protected variable. But I figured that this technique could be inefficient when lots of accesses have to be made to those encapsulated variables because functions must be used to retrieve data.

So I've come up with a different solution that might be better. Hopefully i'm explaining ok what I want to achieve.

I want to know whether this technique is good or not ?

Basically, all I have to do is create a header file or a macro something like this :

#define FRIENDTOALL \
	friend Class1; \
	friend Class2; \
	friend int function(); \
	friend int main();

So it contains all the classes and functions in the program.
And then place the FRIENDTOALL macro in each class that contains encapsulated members.
That way it's possible to access private and protected variable members from anywhere in the program and still be able to see that they are not meant to be modified without using a class's functions.

Would it be wise to use this technique so I can see what variables are not to be modified without using member functions or are there any noticable draw backs to doing it this way ?

modified on Monday, December 28, 2009 9:46 AM

Jimmanuel26-Dec-09 14:44

Jimmanuel

26-Dec-09 14:44

I wouldn't really call this a good encapsulation technique, it's more like an anti-encapsulation technique. The whole point of making things protected and private is so that other classes can't access them directly, making every class a friend blows that idea out of the water. At that point why not just make everything public?

doug25 wrote:
prevent these from being changed elsewhere in a program

Oh yeah, that's why we don't want to make everything public.

Especially with judicious use of inlining, the performance hit of using getters/setters is minimal in the grand scheme of things.

Badger | [badger,badger,badger,badger...]

Badger | [badger,badger,badger,badger...]

Re: good encapsulation technique ? [modified]

«_Superman_»26-Dec-09 16:43

«_Superman_»

26-Dec-09 16:43

doug25 wrote:
But I figured that this technique could be inefficient when lots of accesses have to be made to those encapsulated variables because functions must be used to retrieve data.

I think you're wrong here in the first place.
The latest compilers will definitely optimize the function calls with direct access.
You should turn on full optimization and check the assembly output that is generated.

I recommend you do not worry about optimization unless you're actually facing some sort of bottle neck.
'Cause you're simply ruining code encapsulation and more than that readability which will ultimately lead to a maintenance nightmare.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

doug2527-Dec-09 0:05

27-Dec-09 0:05

Thanks for the comments,

EDIT:

with optimizations turned on, using value = var.var is 1.3 times faster than using a function like value = var.var(). But at millionth's of a second for getting a value 900 million times.

~~woops, I used an unsigned int for a very big loop, so the value wasn't actually retrieved 900 million times~~. I recalculated (incrimenting a double for loops) and found that one hundred million value = var.var is 1.0366 times faster than one hundred million value = var.var()

oh, unsigned ints have range 0 to 4,294,967,295

So I guess there isn't much difference in speed using a function to retrieve values. Smile | :)

nevertheless, that was really silly of me, I could easily achieve the same effect as what I originally intended by :

class Class1
{
protected:
//public:
	int var;
}

and then uncomment public: when building a project.

The reason I would want to do this is because to me, protected values should be values that can be read from but not written to (outwidth the class), so when editing using intellisense it's useful for me to see what variables I intend to be protected in the "Let me know when it's ok and when it's not ok to change them" sense.

But I would probably only do this when i'm editing code, otherwise make variables always public if someone else is editing it. see what I mean.

but given that the speed difference of using a get function is so minute, I'll probably start using get functions. though for certain special cases I might want to treat a variable as "protected" but still be able to change it in different scopes so my technique might be useful there.

Cedric Moonen27-Dec-09 1:53

Cedric Moonen

27-Dec-09 1:53

doug25 wrote:
protected values should be values that can be read from but not written to (outwidth the class)

You should revise a bit your C++ books Smile | :)

. Protected doesn't mean that at all. It simply means that the classes which are inheriting from your class will have access to all protected members (as if they were public) but the rest of your program won't be able to access to members. If a member is private, then the inheriting classes can't access these members. (This is only valid for public inheritance, which is the most common used).

Anyway, what you are doing makes the code horribly hard to maintain because if another programmer reads your code, he won't be able to understand anything of what you were trying to do. As others already said, use getters/setters and turn on optimization, this is by far the best solution because it is standard.

Cédric Moonen
Software developer

Charting control [v2.0]
OpenGL game tutorial in C++

doug2527-Dec-09 2:05

27-Dec-09 2:05

yes, I know what protected means Smile | :)

, I think for projects that aren't personal i'll use the get standard, but I'm not keen on it because sometimes it could be useful to be able to modify protected members in global scope, so I've come up with the following to compensate for the rare circumstances :

//#define EDITINGCODE

#ifdef EDITINGCODE
	#define PROTECTED protected
#else
	#define PROTECTED public
#endif

// Using PROTECTED allows the declaration of
// member variables that shouldn't be modified
// without using member functions
// while they can be read from
// within any scope

class Class1
{
PROTECTED:
	int var;
};

thanks for the advice however

BonshatS27-Dec-09 3:14

BonshatS

27-Dec-09 3:14

You're hardly "protecting" them by making them public for reading and writing.

Why not make the get public and the set protected?

I'm not totally clear on why you're trying to do this, but if it's only to make Intellisense behave the way you want, then I would'nt be changing code for it.

doug2527-Dec-09 6:02

27-Dec-09 6:02

yes, PROTECTED doesn't actually protect the member variables but it lets me see what variables aren't supposed to be changed in normal circumstances without using member functions.

PROTECTED member variables are public at compile time but when i'm editing code, intellisense will inform me that changing them directly is "dangerous" while their values can safely be read.

So the reason for using it is that I can see more clearly how certain member variables were indended to be used, to make editing code easier. And also, because it seems unnecessary to use get functions when I could read directly from a variable. I like the coding style, but if I was going to do a project involving more people then I'd resort to the standard way. I think it should be possible to read from protected variables but not write to them so having PROTECTED lets me see what variables shouldn't be written to without using class functions but I still have the privaledge to read from them.

Bram van Kampen27-Dec-09 12:03

27-Dec-09 12:03

?????

You're trying to bypass good things that were developed to stop you from doing bad things when writing code, Intellisense was expensively developed to warn you of these things! Someone somewhere spent blood sweath an tears getting it to work. If you don't want it, why not swich it off altogether.

Bypassing it in the manner you suggested would make your code very hard to maintain, and, it allows you to do write the type of code that probably contains latent bugs! Also, if you switch off your Manifest in the Release Version, you end up with two versions: Debug and Retail, which are potentially vastly different. What about 'Surviving the Release'

Smile | :)

Bram van Kampen

doug2527-Dec-09 13:16

27-Dec-09 13:16

No, the use of the PROTECTED macro actually makes code more maintainable and less prone to bugs, because the thing is, for a class in my project I was just going to make all the member variables public anyway but by placing the PROTECTED macro before their declarations, it allows me to see clearly that they are not ordinary public members since they should be changed with precaution when changing their values is required.

And using the macro in my project also makes better use of intellisense since it will show that the member variables are protected which in the case of classes written by myself means they are allowed to be read from but usually shouldn't be written to directly.

Of course some members may use the actual protected access specifier but if somehow a coding mistake is made to access those when they shouldn't be accessed then the compiler will produce errors at compile time where i.e. the PROTECTED macro is turned off (becomes #define PROTECTED public).

Well, I know it maybe doesn't seem like a good idea but while using this technique it's actually working very well in my project. public, protected and private are basically for editing purposes anyway and I can't see why you would decide to try and defy access rights to member variables so the PROTECTED macro seems pretty good cause it makes it easier to see how a member variable is intended to be used. Maybe there's a better name for the macro but PROTECTED suits me Smile | :)

Bram van Kampen27-Dec-09 14:30

27-Dec-09 14:30

Well,

If you think this is a good Idea, so be it! Use it, No-one can Stop you. The point is, you put the question on this forum, expecting a response about whether or not this was a good idea or not. Most members (including Myself) seem to think that it is NOT a good idea.

You, on the other hand seem to think that it is a GOOD Idea, and seem to be looking for approval by the wider community.

And then I hear you say: Historically, many good Idea's were first frowned upon and dismissed by the established scientific community.

Maybe you should not have posted this idea as a question on the forum, but as an Article, titled say 'How to defeat Protected Storage Class Warnings in Intelisense'

That would have been a guide about how to do something, rather than a question about if what you're doing is good or bad.

Bram van Kampen

Re: good encapsulation technique ? [modified]

Jimmanuel27-Dec-09 14:39

Jimmanuel

27-Dec-09 14:39

doug25 wrote:
the use of the PROTECTED macro actually makes code more maintainable and less prone to bugs

Spend some time actually maintaining code and you'll see just how wrong that statement is.

doug25 wrote:
see clearly that they are not ordinary public members since they should be changed with precaution

Clearly see? Seeing something is worthless without enforcing it, and that's what private/protected is for. I guarantee you that when someone comes along later and sees that they can easily modify the internals of all of your classes because they're public, they'll do it. Unless you design your classes to prevent misuse, they'll be misused and then they'll be broken. When something is public, that means that it's open to the wild and it should be changed however and whenever the programmer wants.

One of the general principals in OO is that objects should interact with each other through their public interfaces and not care about each others internal states. When you violate this it generally means that classes are too tightly coupled and therefore not very reusable (and hence, not well defined). This is such a fundamental concept of OO that C# has turned encapsulation into a feature of the language itself. See Properties[^]. Being able to directly read/write the internal state of other objects shreds this concept completely.

doug25 wrote:
public, protected and private are basically for editing purposes anyway

No, they're not. They are for creating reusable, maintainable, self contained objects with well defined interfaces not just for you but for everyone else that will come along later and use/edit your code.

I agree with Cedric that you may need to go reread a few chapters of your C++ book.

doug25 wrote:
PROTECTED

As a great (fictional) man once said: You keep using that word, I do not think it means what you think it means.[^]

Badger | [badger,badger,badger,badger...]

doug2527-Dec-09 22:52

27-Dec-09 22:52

thanks for the feedback.

well, I think your right. It would be better to just implement get and set functions rather than what I've been doing.

The only possible draw back is speed, but there might not be any difference (I think it's just my own paranoia getting to me).

Superman suggested I could check the assembly output, does this mean the assembly code that is produced when code is compiled to read a variable from a get function and read a variable directly ? I don't know how to check the assembly output or what part of it to examine ?
Ok, the assembly / machine code output of variable = instance.getVar() is not the same as variable = instance.var

I took timed measurements (optimizations on), reading from a variable directly seemed faster than using a function, but I'll reimplement the code for my actual project and see if there's a noticable difference in speed. If there isn't then I think I'll have to agree that in 99.99% or 100% of cases, it would be better to use the standard method.

modified on Monday, December 28, 2009 5:39 AM

doug2528-Dec-09 1:33

28-Dec-09 1:33

I've removed the macro I was using in my project and I'm using the standard protected access specifier with get and set functions as people have recommended, and the difference in fps (with VSync turned off) is unnoticable.

So the classes are correctly encapsulated, coded in a standard format and there's no drop in performance.

So you were all right that making variables protected and accessing them through get functions is probably in 100% of cases the best way to go, when direct outside modification to variables should be prevented.

thanks for all the advice.

Jimmanuel28-Dec-09 3:05

Jimmanuel

28-Dec-09 3:05

I'm glad that you've come around. Wikipedia has a good little collection of quotes about code optimization that you might like: clickety[^]

Badger | [badger,badger,badger,badger...]

doug2528-Dec-09 3:37

28-Dec-09 3:37

thanks very much. Smile | :)

useful quotes.

Bram van Kampen28-Dec-09 13:05