NewLC - Why use TBool vs. bool? - Comments

Re: Why use TBool vs. bool?

euroq — Wed, 07 Feb 2007 16:26:16 +0100

Quote from: fig7

Anyway it would work fine if it was Symbian doing the hacking

My guess is all they have to do is

typedef bool TBool;
#define ETrue true
#define EFalse false

Unfortunately, Symbian has just promised that Symbian 3rd Edition (OS 9) is going to be binary compatible from now on. Which means they (or we) might have just lost the last opportunity to fix these problems that depend on compatibility with older editions.

-euroq

Re: Why use TBool vs. bool?

fig7 — Fri, 02 Feb 2007 02:14:23 +0100

Quote

That would be a disaster! If you changed the headers of the SDK, every SDK method which uses a TBool would be compiled wrong in your code.

Good to see you spotted that

I suspect that your app simply wouldn't link. The linker would be looking for Symbian OS functions using bools but it would only find ones that used ints!

Anyway it would work fine if it was Symbian doing the hacking

My guess is all they have to do is

typedef bool TBool;
#define ETrue true
#define EFalse false

Quote

By the way, how do you know that the people at Symbian don't use GCCE, what do they use instead?

ARM don't just make the processors they also provide a compiler for them:
http://www.arm.com/products/DevTools/RealViewDEVELOP_Family.html

Re: Why use TBool vs. bool?

euroq — Thu, 01 Feb 2007 22:23:29 +0100

Quote from: fig7

I think it's probably possible to just hack the header (e32std.h ?) so that TBool becomes a bool. You might also be able to fix the annoying warnings that GCCE generates about ETrue and EFalse being different enums.

That would be a disaster! If you changed the headers of the SDK, every SDK method which uses a TBool would be compiled wrong in your code. The worst thing is, probably a lot of your program would work and then all of a sudden crash.

But it sure would be awesome to get rid of the ETrue/EFalse warnings, without having to cast every single comparison!

By the way, how do you know that the people at Symbian don't use GCCE, what do they use instead?

Re: Why use TBool vs. bool?

euroq — Thu, 01 Feb 2007 22:18:37 +0100

Quote from: zingmagic

I did this on the only two that matter: the emulator and the device. Also, I can positively say that the compiler is always going to be able to optimize a native bool type better than TBool. The two examples show this. (However, I'm not saying that every use of a bool vs. int will be better optimized... obviously some code will always look the same, whether it's an int or a bool).

Quote

a primary reason is that you often dont save much, e.g. in a struct containing a bool followed by an int you will use 8 bytes regardless of bool only being a byte in size on the armi platforms since it has to align ints on 4 byte boundries.

Yes I know about machine word alignment. And once again, the compiler will handle this. It will align them in structs, it will also pass bools in whatever method is best, and create optimized conditionals with bools better than ints. Point is, you will (well, can in most instances) save something by switching from ints to bools.

Quote

Bit like asking why use TInt instead of default compiler option for ints. Good practice + any complier differences and/or enchancements can be taken advantage of as required by a single change of the data type definition.

Its no accident that practically all platforms choose to define their own data type sets...

Agreed. C's history has always been all about making the code work best for the platform it's compiled for, not for all platforms. Which is why we have abstract data primitives (int, long), so that it maps to the machine the best. So if you're always using primitive data types, and expecting them to be a certain way cross-platform (i.e. 32 bits), you're going to run into trouble. C99 now has some new primitive types such as Int8, Int16, Int32, etc.

Still, the point is that TBools aren't as optimizable as bools.

Re: Why use TBool vs. bool?

metalim — Tue, 30 Jan 2007 17:47:11 +0100

Quote from: fwojtek

Don't even think about "standard C++" in Symbian, while you have to support "Leaves".
But if "Leaves" were changed to C++ exceptions, THAT would be one and only MAJOR development speedup.

Re: Why use TBool vs. bool?

Holloway — Tue, 30 Jan 2007 10:26:37 +0100

Apart from good practice hiding the variable 'native' data types (just because youve disassembled the code and seen what it does with one complier on a couple of platforms, what makes you think all compliers will manage to do the same thing ?.) a primary reason is that you often dont save much, e.g. in a struct containing a bool followed by an int you will use 8 bytes regardless of bool only being a byte in size on the armi platforms since it has to align ints on 4 byte boundries.

Bit like asking why use TInt instead of default compiler option for ints. Good practice + any complier differences and/or enchancements can be taken advantage of as required by a single change of the data type definition.

Its no accident that practically all platforms choose to define their own data type sets...

Re: Why use TBool vs. bool?

fig7 — Mon, 29 Jan 2007 23:44:30 +0100

Quote

They probably figured this would break backwards compatibility.Â But with the release of Symbian 3rd Edition, as it is a binary-break release, this would have been a perfect time to change it.

Yes, it would and they should have done it. But inevitably they had to find the right balance between changing things and maintaining backwards compatibility. It probably wasn't something that was considered very important (and in the big scheme of things it isn't). The key changes were the new kernel, platform security,Â and the change over to use a completely new tool chain (GCCE / ARM compilers). Those were the things thatÂ really mattered.

What's most annoying about them not changing this is that GCCE generates warnings every time you use ETrue and EFalse in the same expression (e.g bigY = (y>2) ? ETrue : EFalse). Of course the people at Symbian wouldn't have noticed this as they don't use GCCE!

Quote

I also cant figure out why to use TInt instead of int???

For me this is all about good object orientated design. That everything in your code has a clear purpose: any class of objects beginning with T are essentially passive blocks of data. Any class beginning with R represent a handle to a resource of some kind (which you "borrow" from the system). Any objects of C classes are actors within your program: they are things that "do stuff".

In terms of making code more portable my advice is to always try to seperate your code into the components that have to be portable and those that have to interface with the OS. In the portable parts you may as well use bools and standard C++ exceptions (these work on Symbian now, or at least I think they do. Can somebody confirm this?) but in the OS specific stuff I would continue to follow the Symbian coding guidelines.

Re: Why use TBool vs. bool?

fwojtek — Mon, 29 Jan 2007 22:15:13 +0100

With symbian 9 they had a long time to change most of suc**ng things in Symbian C++...

I now think to use more of standard c++ on symbian 9. Developement will be easier, and code will bo more portable. I use bool for my staff and TBool only if its needed by some symbian functions....

I also cant figure out why to use TInt instead of int??? This works the same. Only convetion is another...

Re: Why use TBool vs. bool?

euroq — Mon, 29 Jan 2007 20:52:03 +0100

Quote from: fig7

Although only a single bit would theoretically be necessary to represent a
Boolean, a machine word is used instead, so that these quantities can be easily
passed. Also, TBool must map onto int because of C++'s interpretation of
operands in conditional expressions.

One wise thing I learned in school is to never try to outsmart the compiler. The compiler can figure out the best way to pass a bool (if it wants to send the bool as 4 bytes to align it to a machine word, that's fine with me). From now on in, I'm using exclusively bool instead of TBool.

Quote

On implementations of Symbian OS in which the compiler supports the ANSI-recommended bool type, TBool will be typedef'ed to bool instead of int.

They probably figured this would break backwards compatibility. But with the release of Symbian 3rd Edition, as it is a binary-break release, this would have been a perfect time to change it.

-euroq

Re: Why use TBool vs. bool?

fig7 — Sat, 27 Jan 2007 00:21:34 +0100

If you look in the headers you'll probably find that TBool is typedef as an int (or a TInt)
It's for historical reasons really, early compilers didn't have a bool type. I'm not sure why Symbian haven't changed it: probably because "they say that if it isn't broke don't fix it"

More to the point your analysis is correct: that the compiler should be able to optimise better if it knows a variable can only have true or false values.

I think it's probably possible to just hack the header (e32std.h ?)Â so that TBool becomes a bool. You might also be able to fix the annoying warnings that GCCE generates about ETrue and EFalse being different enums.

Just checked the header file (e32def.h):

/**
@publishedAll
@released

Boolean type which takes the value either ETrue or EFalse.

Although only a single bit would theoretically be necessary to represent a
Boolean, a machine word is used instead, so that these quantities can be easily
passed. Also, TBool must map onto int because of C++'s interpretation of
operands in conditional expressions.

On implementations of Symbian OS in which the compiler supports the ANSI-recommended
bool type, TBool will be typedef'ed to bool instead of int.
*/
typedef int TBool;

I guess they forgot to change itÂ

Re: Why use TBool vs. bool?

tote — Fri, 26 Jan 2007 23:55:53 +0100

My guesses are as follows:
- TBool starts with a 'T', whereas 'bool' doesn't ==> remember TAny and coding convention!
- Maybe 'bool' keyword was not available when Symbian basic datatypes were worked out?

I don't think the reason is more complex!

Tote

Why use TBool vs. bool?

euroq — Fri, 26 Jan 2007 19:51:43 +0100