Register syntax

[vorticidal]

When I try declaring something like this:

register int x;
register char z;
register struct something;
register short int something_else;
register etc etc;

my devcpp compiler keeps on whining about 'register name not specified'.

I thought using register type type worked?

[Timaster]

I don't think register does what you think it does... you might be looking for "typedef"? :)
http://www.cplusplus.com/doc/tutorial/other_data_types.html

[Smok006]

Maybe it helps: http://www.cplusplus.com/forum/beginner/1401/

So...what can I say....I'm using also Dev-c++, but I don't have any problem. So it will help if u give some more infos.

[vorticidal]

Weird...
I made another script, and there's no problem with it...
Yet, it's Ctrl+c'ed from the prototype...
Murphy's law is out and about, I guess:)

[jsmith]

The keyword "register" is all but deprecated these days. Why are you trying to use it?

[vorticidal]

Well, I'm taking part in a programming competition these days, and, since I don't know whether they'll auto optimise the code, I thought of some cheating or optimisation, you call on what actually it is.

BTW, char's and int's roll back from zero when past their limit, while bool's don't.
Check this out:

#include<iostream>
using namespace std;
unsigned long county = 0;
unsigned short int count =0;
int main()
{
for(bool b=0;count<=10;b++,count++)cout << b;
cout << "\n";
for(unsigned char c='\0',county=0;count<=512;c++,count++)cout << c;
cout<<"\n";
for(count=0,county=0;county<=(512*256);count+=512,county+=512)cout << count <<"\n";
return 0;
}

[jsmith]

The reason for my original post is because most compilers today are much better at optimizing code / register use than the programmer is. Which makes the register keyword mostly useless, and I believe that at least some compilers simply ignore it.

[firedraco]

Also, you DO know that bool is not a 1 or a 0, it is true or false...if you set a bool to = a number, 0 = false, anything else = true.

[Timaster]

firedraco, I recommend you run these programs:

#include <iostream>

int main()
{
	std::cout << false << '\n' << true;
	for (;;);
}

#include <iostream>

int main()
{
	bool boolean;
	boolean = 5;
	std::cout << boolean;
	for (;;);
}

[firedraco]

firedraco, I recommend you run these programs:

Warning 1 warning C4305: 'initializing' : truncation from 'int' to 'bool'

bool boolean;
	boolean = 5;
	std::cout << boolean; //this couts 1 

[Timaster]

Yep :)
Bools don't store anything but a 1 or 0. So

bool is not a 1 or a 0

isn't quite accurate =P

You are right in that casting any nonzero value to a bool returns 1, but a bool variable is only 1 or 0.

[exception]

What your ostream makes of a bool has nothing to do with what a bool is (heared of boolalpha?) What implicit conversions are allowed with a bool has as little to do with what a bool is. What you describe is implementation-defined behavior. It may work on your compiler (version+OS(version)). It may not work on mine. There actually *is* a reason why a bool isn't an enum, typedef, define, or whatever else.

[Timaster]

Fair enough on the ostream thing. Let's do it bitwise. We'll put 00000011 into the boolean, and then flip the last bit. If it stores 00000011, flipping the last bit will still leave it true. If I'm right, and it stores 00000001, then flipping the last bit will leave it false.

#include <iostream>

int main()
{
	bool boolean;
	boolean = 3;
	boolean = boolean ^ 1;
	std::cout << boolean;
	for (;;);
}

Maybe there are implementations that allow the other bits to be used. But there are certainly implementations that don't.

[exception]

Maybe there are implementations that allow the other bits to be used. But there are certainly implementations that don't.

What a nice definition of 'implementation-defined behavior'... but what I (and most people I deal with) understand under the term "C++" is the language defined in ISO 14882. And it states:

The Boolean literals are the keywords false and true. Such literals have type bool. They are not lvalues.

It doesn't require bool to have byte size. And while it can be converted to one, a bool is not a numeric value:

An rvalue of type bool can be converted to an rvalue of type int, with false becoming zero and true becoming one.

Since the conversion goes the other way around, it may seem as if a bool were a numeric type:

An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

...but nonetheless bitwise operations are undefined, since the representation of a bool, while guaranteed to be binary and "like a" number, is undefined in it's length (you'll have to look up that one yourself). So long story short: bool literals are true and false and nothing else, and if you do arithmetic with bools, you are writing unportable code (and if you use implicit conversions, you better know them well if you don't want to spend endless hours in pain trying to figure out the problem).

[Timaster]

I'm not sure why we're stuck on the implementation thing. I think we both agree that

bool is not a 1 or a 0

isn't a true statement, and

bool is a 1 or a 0

isn't true either. Sometimes it is a 1 or 0, sometimes it's not.

As for the byte thing, I did not know this. It's true though, Microsoft, in their infinite wisdom, decided to typdef a bool to an int in a version of VC++, giving bool a size of 4 bytes.

Finally, I'm slightly confused about the difference between a "bool", which is obviously an lvalue, since you can assign things to it, and a "Boolean literal", which is an rvalue... maybe I don't fully understand the difference between lvalue and rvalue?
Regardless, I don't see why you think bitwise operations are undefined for bools. They're 1's and 0's, are they not?

[exception]

I'm not sure why we're stuck on the implementation thing. I think we both agree that
bool is not a 1 or a 0
isn't a true statement, and
bool is a 1 or a 0
isn't true either

You've got to check your logic. A statement is either true or false. It isn't both. And a bool does *not* have the value either "0" or "1", it has the value either "true" or "false", as I thought would become clear from the passages I quoted above.

typdef a bool to an int

...is a great idea, especially since then

void f(int x);
void f(bool x);

cannot be defined in the same program, which is, according to the standard, a perfectly legal overload situation.

the difference between a "bool" [...] and a "Boolean literal"

A boolean literal is a literal assignable to a variable of type bool, just like 5 is an integer literal, 5.0 is a double literal etc. Obviously, false and true are rvalues.

[Timaster]

What I meant by the first part is that in some implementations, the value of a boolean is limited to 00000001 or 00000000, but in others it's not. That the runtime reads 00000001 as true and 00000000 as false is a different story altogether.

Also, why is that a great idea? That's 3 extra bytes and unnecessary limitations on overloading. Unless you were being sarcastic.

A boolean literal is a literal assignable to a variable of type bool, just like 5 is an integer literal, 5.0 is a double literal etc. Obviously, false and true are rvalues.

Ah. Well, the two boolean literals are true and false, but the values of a boolean variable can be 00000001 and 00000000 in some implementations, or nonzero and 00000000 (give or take a few 0s depending on how many bytes it is).

[jsmith]

I think a lot of the confusion here is over C++'s implicit conversion to bool.
Any numeric type can be implicitly casted to bool. (This can be annoying and is why the safebool idiom was invented.)

So any arithmetic operations performed on a boolean require first the boolean to be implicitly converted to an integer type. The arithmetic operation is then performed in the integer/floating point domain. When the result is assigned back to a bool, it it implicitly converted back to bool.

Most compilers when implicitly converting a bool to an integral type will convert false to 0 and true to 1. (I do not believe this is mandated by the standard). However all compilers when implicitly converting a numeric type to bool will convert the value zero (or its equivalent) to false and anything else to true.

So to use an example above, with commentary:

bool boolean;

// Compiler implicitly casts the integer '3' to bool.  According to standard, this is 'true'.
boolean = 3;

// Compiler implicitly casts 'true' to an integer.  GCC, eg, converts it to the integer '1'.
// 1 ^ 1 == 0.  Zero is then implicitly casted back to bool according to the standard
// which means 'false'.
boolean = boolean ^ 1;