C / C++ / MFC

26-Feb-02 10:20

which one is "better"?

i know bool is more standardized but BOOL is more efficient, but which one is more commonly used, furthermore, which one should i use?

>>Roman<<

Carlos Antollini26-Feb-02 10:29

Carlos Antollini

26-Feb-02 10:29

You answered your question. I think that is better to use the more efficient...
Do you prefer to use while(true) or for(;;)? Big Grin | :-D

Regards!!!

Carlos Antollini.
Sonork ID 100.10529 cantollini

Tim Smith26-Feb-02 10:25

Tim Smith

26-Feb-02 10:25

while(true) and for(...) take the same amount of time. I have yet to see a compiler not optimize while (true) away.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Felix Cho26-Feb-02 10:24

Felix Cho

26-Feb-02 10:24

Is bool less efficient? I don't think so...

I usually use bool for pure C++ logic, and BOOL for UI/Win API related stuff.

I have seen a lot of people mixing them and IMHO is not a good idea in terms of readability.

Tim Smith26-Feb-02 10:24

Tim Smith

26-Feb-02 10:24

BOOL edges out bool in performance just by a very tiny amount.

Here are the rules I use.

If I am doing WIN32 code, I use BOOL. Otherwise, for the other 90% of my code, I use bool.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Mukkie28-Feb-02 11:42

Mukkie

28-Feb-02 11:42

Hi!

Try this:
bool test_a = 3;
BOOL test_b = 3;
or that one:
bool test_a = true;
switch(test_b)
{
case 4:
break;
case 5:
break;
}
and the same for BOOL.

You will see the difference Smile | :)

Moreover: sizeof(BOOL) != sizeof(bool) ===> 4 != 1

I use always bool's, but when I deal with Win32 - I use BOOL's.

Mukkie

Roman Nurik26-Feb-02 10:27

26-Feb-02 10:27

thanks, so for libraries i make, ill use bool if they're not windows-specific ;D

>>Roman<<

is this good practice?

Roman Nurik26-Feb-02 10:17

26-Feb-02 10:17

frst of all, thanks to Bill Wilson for answering my naming conventions post Big Grin | :-D

i realized that many of my classes have Get/Set members for very simple variables like integers or such. it's very annoying to manage these functions as the member variables change data type and name a lot throughout my coding process.

is it good practice to make the member variables just public (and not have "m_" precede them) or is there some easy way to manaage Get/Set functions?

also, if public member variables is the way to go, i'd like to have a pointer class to manage dynamic memory and stuff like that.. sort of like a smart pointer... is there an already existing class that would allow for that or do iu have to make one?

p.s. i tried auto_ptr but it seems that that class only sets the pointer in its constructor Frown | :(

>>Roman<<

Nemanja Trifunovic26-Feb-02 10:27

Nemanja Trifunovic

26-Feb-02 10:27

RomanNY wrote:
is it good practice to make the member variables just public

NO!!!

I vote pro drink Beer | [beer]

Roman Nurik26-Feb-02 10:24

26-Feb-02 10:24

well is there a tool to manage the get/set functions then? im using VC++ 6

>>Roman<<

Christian Graus26-Feb-02 10:54

Christian Graus

26-Feb-02 10:54

Yes, there is a big window where you will find your class definition. Add Get/Set methods there as appropriate.

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

Maximilien26-Feb-02 11:01

Maximilien

26-Feb-02 11:01

RomanNY wrote:
well is there a tool to manage the get/set functions then? im using VC++ 6

A keyboard ?

Michael Dunn26-Feb-02 11:41

Michael Dunn

26-Feb-02 11:41

Check out __declspec(property)

--Mike--
"There are three things I can never remember, 1: um... 2: um... 3: um..."
-- Victor Borge
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan and Jamie Salé.

Carlos Antollini26-Feb-02 10:31

Carlos Antollini

26-Feb-02 10:31

I Agree with you...

I say NNNNNNNOOOOOOOO

Also I vote pro drink Beer | [beer]

Carlos Antollini.
Sonork ID 100.10529 cantollini

Jon Hulatt27-Feb-02 1:04

Jon Hulatt

27-Feb-02 1:04

Everone shouts "NO!!" to your question. I'd agree with them, but thought it'd be useful to explain why...

Imagine you've written your class with public members, and for example, you had a char * pointer as a member. Your app is free to both read & write to this pointer as needed.

As your app grows, you want to make it more efficient. So you go multi threaded. You could now get yourself into a situation where one thread is in the middle of reading data from that pointer, but a totally different thread is trying to write!. At best, you get data corruption. At worse, you get a protection error.

If you'd religiously used accessors and mutators, it would be minimal work to prevent this happening. You'd make sure that your accessor and mutator member functions used mutexes (or some other sync object, as appropriate) to police access to the member variable.

The other main reason is readability. Imagine these two lines, which are functionally equivalent:

class CYourClass
{
   public:
     char *m_pBuffer;
}


....


CYourClass *p_YC = new CYourClass

char mystring[]="hello world";

// you want to copy mystring's "hello world" into the class:

// the shite way: confusing to look at-
p_YC->m_pBuffer = new char[strlen(mystring)];
strcpy(p_YC->m_pBuffer, (char *) mystring);

// the easy way:
p_YC->SetBuffer( (char *) mystring);

in that example, you could do clever stuff like having the SetBuffer() mutator handle things like memory allocation for m_pBuffer. It simplifies your code.

Sorry to dissapoint you all with my lack of a witty or poignant signature.

Bill Wilson27-Feb-02 8:05

Bill Wilson

27-Feb-02 8:05

Readability is not the only benefit to encapsulation. The primary reason, in my opinion, is to divorce the audience of a member variable from the derivation of its value.

If you use accesor and mutator methods you can do things like changing the underlying storage or even add qualifications and calculations without impacting the audience of the value.

For example:

Say you have an inventory class that contains a Price variable. Then at a later date, after you've built your app, a buisiness decision is made to vary the price by warehouse location. If you used an accesor (GetPrice), you only need to modify it to accomodate the calculation, rather than modifying every reference to m_price in the entire app.

Just my opinion for what its worth,
Bill

Roman Nurik27-Feb-02 9:43

27-Feb-02 9:43

well i dont plan on storing pointers as member variables, i plan to make classes to control the pointers. the only simple member variables would be maybe integers or such...

e.g.

class MyClass
{
public:
SmartPointer<char> pBuffer;
int nType;

MyClass();
};

i see the problem with this though, that there can be no validation Frown | :(

but the pointer thing shouldnt be a problem as long as auto_ptr or another smart pointer template class is used

>>Roman<<