checking bits

[Mark]

lets say i have a char, and i want to check if the 3rd bit is 0 or 1...
how might i do this?

thanks!

[Mike Wahler]

"Mark" <mn*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

lets say i have a char, and i want to check if the 3rd bit is 0 or 1...
how might i do this?

Learn about the bitwise operators,
e.g. | , & , etc.

Also you should used unsigned characters for this.

-Mike

[Mike Wahler]

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:4e*****************@newsread1.news.pas.earthl ink.net...

"Mark" <mn*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

lets say i have a char, and i want to check if the 3rd bit is 0 or 1...
how might i do this?

Learn about the bitwise operators,
e.g. | , & , etc.

Also you should used unsigned characters for this.

Alternatively, there's the 'std::bitset' type
from the standard library.

-Mike

[Mark]

alright. thanks :)

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial...operators.html

[Shark]

Mark wrote:

alright. thanks :)

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial...operators.html

It will help if you want your answer to be the same regardless of
whether you are on a little endian or big endian machine. What you mean
by the '3rd' bit can have different meanings.

[Shark]

Mark wrote:

alright. thanks :)

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial...operators.html

There is something about bit manipulations using #define here:
http://www.embedded.com/2000/0005/0005feat2.htm

9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear bit
3 of a. In both cases, the remaining bits should be unmodified.

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used. My optimal solution to this problem would
be:

#define BIT3 (0x1
<
<
3)
static int a;

void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

[Victor Bazarov]

Shark wrote:

Mark wrote:

alright. thanks :)

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial...operators.html
There is something about bit manipulations using #define here:
http://www.embedded.com/2000/0005/0005feat2.htm

9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear
bit 3 of a. In both cases, the remaining bits should be unmodified.

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used. My optimal solution to this problem would
be:

#define BIT3 (0x1
<
<
3)

Whoa!... What's wrong with your newsreading software? And why are
you writing "0x1" instead of simply "1"? Is there a difference?
static int a;

void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

And why not have an argument for those functions? Something like

void set_bit3(int &a) { a |= BIT3; }

? Otherwise you only can use those functions to set or clear the
bits in some static object named 'a' in this translation unit...

V

[Shark]

> And why not have an argument for those functions? Something like

void set_bit3(int &a) { a |= BIT3; }

? Otherwise you only can use those functions to set or clear the
bits in some static object named 'a' in this translation unit...
Well, I simply copied and pasted the code from
http://www.embedded.com/2000/0005/0005feat2.htm . The question was
aimed at programmers for embedded systems. Maybe they like coding this
way! But yes, if i were to write this code, I'd pass an argument and
not use a static int.

V

[Jim Langston]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:cL******************************@comcast.com. ..

Shark wrote:

Mark wrote:

alright. thanks :)

this should help anyone else who cares to know
http://www.cprogramming.com/tutorial...operators.html

There is something about bit manipulations using #define here:
http://www.embedded.com/2000/0005/0005feat2.htm

9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear
bit 3 of a. In both cases, the remaining bits should be unmodified.

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used. My optimal solution to this problem would
be:

#define BIT3 (0x1
<
<
3)

Whoa!... What's wrong with your newsreading software? And why are
you writing "0x1" instead of simply "1"? Is there a difference?

Personally, I've always wanted to be able to do something like:
#define BIT3 0b00000100
but 0x is as close as you can get.
At least it gives the intent. Which would be the same reason he wouldn't do
#define BIT3 4
because the intent of 4 is not clear.

[Mark]

Jim Langston wrote:

Personally, I've always wanted to be able to do something like:
#define BIT3 0b00000100
but 0x is as close as you can get.
At least it gives the intent. Which would be the same reason he wouldn't do
#define BIT3 4
because the intent of 4 is not clear.

well... the point of defining BIT3 as 4 would be so that it WOULD be
clear when you used "BIT3".. the definition itself doesn't need to be
quite so clear does it? anyways "BIT3" should tell you something about
your intent.

thanks for the help again guys.

[Shark]

Mark wrote:

Jim Langston wrote:

Personally, I've always wanted to be able to do something like:
#define BIT3 0b00000100
but 0x is as close as you can get.
At least it gives the intent. Which would be the same reason he wouldn't do
#define BIT3 4
because the intent of 4 is not clear.

well... the point of defining BIT3 as 4 would be so that it WOULD be
clear when you used "BIT3".. the definition itself doesn't need to be
quite so clear does it? anyways "BIT3" should tell you something about
your intent.

The meaning of "clear" is not clear here. Do you mean clear as in
clarity or clear as in "clear the bit"?

besides. if we #define BIT3 0b00000100 it assumes that we are working
on a 8-bit number, while in C++ the most basic unit (i could be wrong)
int is at least 2 bytes. With (0x1<<3) we just don't have to tell what
size primitives we are working on. At least that is my guess. Again, I
could be wrong.

[Luke Meyers]

Shark wrote:

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used.
Portable, sure. Type-safe, no. Maintainable, no. Recommendable,
absolutely not.

This is what const is for.

const unsigned char BIT3 = ...
#define BIT3 (0x1<< 3)
So you're starting counting at 0? I love zero-indexing as much as the
next fella, but that's not a reasonable convention when speaking in
terms of ordinal numbers. The rightmost bit is the first bit, not the
zeroth bit. The bit pattern you've produced is 00001000. Surely we
can all agree that's the *fourth* bit?
void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

Pretty appalling. Why on earth would someone write a function specific
to one bit position? I'd vastly prefer something like the following
(switching back to zero-index mode):

typedef unsigned char Byte;

inline Byte const nth_bit(size_t n) { return 0x1 << n; }
inline Byte const set_bit(Byte src, size_t n) { return src |
nth_bit(n); }
inline Byte const clear_bit(Byte src, size_t n) { return src &
~nth_bit(n); }

Luke

[Luke Meyers]

Shark wrote:

Mark wrote:

well... the point of defining BIT3 as 4 would be so that it WOULD be
clear when you used "BIT3".. the definition itself doesn't need to be
quite so clear does it? anyways "BIT3" should tell you something about
your intent.
The meaning of "clear" is not clear here. Do you mean clear as in
clarity or clear as in "clear the bit"?

Clarity.
besides. if we #define BIT3 0b00000100 it assumes that we are working
on a 8-bit number, while in C++ the most basic unit (i could be wrong)
int is at least 2 bytes. With (0x1<<3) we just don't have to tell what
size primitives we are working on. At least that is my guess. Again, I
could be wrong.

You are wrong. The most basic unit is char. See section 3.9.1 of the
standard. That said, the size of a char is not guaranteed to be 8
bits. However, as in mathematics, leading zeros are implicit. That's
why we can say 0x1 rather than 0x0001 or 0x00000001.

Luke

[Shark]

Well, once again you are forgetting the context. That question and the
remark I posted was from an embedded programmer's perspective. They
worry too much about how many functions are defined where, how much
memory and crap are assigned.

Luke Meyers wrote:

Shark wrote:

* Use #defines and bit masks. This is a highly portable method and is
the one that should be used.

Portable, sure. Type-safe, no. Maintainable, no. Recommendable,
absolutely not.

This is what const is for.

const unsigned char BIT3 = ...

#define BIT3 (0x1<< 3)

So you're starting counting at 0? I love zero-indexing as much as the
next fella, but that's not a reasonable convention when speaking in
terms of ordinal numbers. The rightmost bit is the first bit, not the
zeroth bit. The bit pattern you've produced is 00001000. Surely we
can all agree that's the *fourth* bit?

void set_bit3(void) { a |= BIT3; }
void clear_bit3(void) { a &= ~BIT3; }

how does this sound!

Pretty appalling. Why on earth would someone write a function specific
to one bit position? I'd vastly prefer something like the following
(switching back to zero-index mode):

typedef unsigned char Byte;

inline Byte const nth_bit(size_t n) { return 0x1 << n; }
inline Byte const set_bit(Byte src, size_t n) { return src |
nth_bit(n); }
inline Byte const clear_bit(Byte src, size_t n) { return src &
~nth_bit(n); }

Luke

[Luke Meyers]

Shark wrote:

Well, once again you are forgetting the context. That question and the
remark I posted was from an embedded programmer's perspective. They
worry too much about how many functions are defined where, how much
memory and crap are assigned.

Please don't top-post. I don't know what you mean by "once again," nor
do I see how anything I said is any less applicable to embedded
programmers. On the contrary, defining a *single* function to handle
bit-setting logic rather than a separate function for each individual
bit is exactly the kind of economy embedded systems programmers are
concerned with.

What exactly did you think was wrong about what I said? Would you care
to comment on the relative technical merits of the two solutions?

Luke

[Shark]

Luke Meyers wrote:

Shark wrote:

Well, once again you are forgetting the context. That question and the
remark I posted was from an embedded programmer's perspective. They
worry too much about how many functions are defined where, how much
memory and crap are assigned.
Please don't top-post. I don't know what you mean by "once again," nor
do I see how anything I said is any less applicable to embedded
programmers. On the contrary, defining a *single* function to handle
bit-setting logic rather than a separate function for each individual
bit is exactly the kind of economy embedded systems programmers are
concerned with.

Oh well, the evils of top posting :p

I use google to read this ng so I see a nice "thread" of everyone's
replies and OP and sometimes I forget to scroll all the way down and
snip this and snip that because the context is a couple of lines above.
My bad.
This thread on google is here:
http://groups.google.com/group/comp....12efb881?tvc=2

I made the original quote from this link:
http://www.embedded.com/2000/0005/0005feat2.htm

The particular question 9 reads as follows:

Bit manipulation
9. Embedded systems always require the user to manipulate bits in
registers or variables. Given an integer variable a, write two code
fragments. The first should set bit 3 of a. The second should clear bit
3 of a. In both cases, the remaining bits should be unmodified.

and the solution was:

#define BIT3 (0x1
<
<
3)
static int a;

copied verbatim (and source was mentioned in my post). So basically
I've been corrected a couple of times for something I referenced from
another site :) I only know that the question was aimed at embedded
programmers and maybe someone who actually works as one can tell why
you'd write a macro to set some bit.

I worked on windows ce devices once and there were some weird things
going on all over the code, but the terminal was fast enough (400mhz)
to run badly written mfc apps that leaked memory. There were also some
hardcore programmer who programmed for single chip barcode scanners and
tried to squeeze out every single clock cycle they could. Frankly I
don't know what is the reason behind this #define except that it helps
skip some symbols that a code-with-functions will put in the compiled
code. But as always, I could be wrong. I don't have much experience in
the industry.
What exactly did you think was wrong about what I said? Would you care
to comment on the relative technical merits of the two solutions?

First, I didn't really say you were wrong. I wanted to say that the
posting I made wasn't really a general solution, but was an answer to a
question. The question made a specific demand.: write two functions
that do the following, and the given answer satisfied the requirement.
So I was only pointing out the context.

Regarding the relative merits, I'd like to run away from the battle so
I can fight another day. I just don't have enough experience with
embedded devices to make a comparison. Maybe someone else can shed a
light. I hope the meaning of "is" is "clear" now! Peace

[Luke Meyers]

Shark wrote:

I made the original quote from this link:
http://www.embedded.com/2000/0005/0005feat2.htm
Ah, no wonder. It's not even a C++ article, it's explicitly a C
article. How embarassing! ;)
So basically
I've been corrected a couple of times for something I referenced from
another site :) I only know that the question was aimed at embedded
programmers and maybe someone who actually works as one can tell why
you'd write a macro to set some bit.
Well, you referenced it; presumably you thought it was somehow
relevant/helpful.
First, I didn't really say you were wrong. I wanted to say that the
posting I made wasn't really a general solution, but was an answer to a
question. The question made a specific demand.: write two functions
that do the following, and the given answer satisfied the requirement.
So I was only pointing out the context.
I could get on your case for disregarding the *relevant* context (a C++
newsgroup, the OP's question etc.), but... nah.... ;)
Regarding the relative merits, I'd like to run away from the battle so
I can fight another day.

Werd, and cheers to that. Nice posting with you.

Luke

[Shark]

Luke Meyers wrote:

Shark wrote:

I made the original quote from this link:
http://www.embedded.com/2000/0005/0005feat2.htm
Ah, no wonder. It's not even a C++ article, it's explicitly a C
article. How embarassing! ;)

So basically
I've been corrected a couple of times for something I referenced from
another site :) I only know that the question was aimed at embedded
programmers and maybe someone who actually works as one can tell why
you'd write a macro to set some bit.

Well, you referenced it; presumably you thought it was somehow
relevant/helpful.

Yes it is helpful. That example provided a way to set/unset 3rd bit of
an int. And I was referencing it because it is useful to the OP's
purpose.

If you can explicitly set the 3rd bit of the char's copy, and then
compare the result with the original then you can determine if the 3rd
bit is set or not.

int check3rdbit(char a)
{
char a='A';
char b= set3rdbitof(a); //returns a char with 3rd bit set
explicitly
if(a==b) then return THIRD_BIT_IS_SET;
else return THIRD_BIT_IS_NOT_SET;
}

I thought that should be obvious ;) So I wasn't off topic. Plus, if its
explicitly C, what makes it not C++? after all that page wasn't
discussing implicit void* casts to char* and like!!!
I could get on your case for disregarding the *relevant* context (a C++
newsgroup, the OP's question etc.), but... nah.... ;)

haha. "Quien en tiempo huye, en tiempo acude."

[Luke Meyers]

Shark wrote:

If you can explicitly set the 3rd bit of the char's copy, and then
compare the result with the original then you can determine if the 3rd
bit is set or not.

int check3rdbit(char a)
Yes, but the point is that it's just silly to hard-code '3' into the
function. What happens when you're interested in bit 4 and bit 7?
Write two new functions? Or write a single function that can handle
any of these cases?
I thought that should be obvious ;) So I wasn't off topic. Plus, if its
explicitly C, what makes it not C++? after all that page wasn't
discussing implicit void* casts to char* and like!!!
Well, C is not C++. The fact that C++ has a C-like subset does not
mean that any "good C practice" is a good C++ practice. Implicit void*
casts to char are one example. Another is the use of #define for
constants. There's absolutely no reason to do that in C++.

Nobody said it was off-topic. Just lousy advice.
haha. "Quien en tiempo huye, en tiempo acude."

Vad sa du?

Luke

[Shark]

Luke Meyers wrote:

Shark wrote:

If you can explicitly set the 3rd bit of the char's copy, and then
compare the result with the original then you can determine if the 3rd
bit is set or not.

int check3rdbit(char a)
Yes, but the point is that it's just silly to hard-code '3' into the
function. What happens when you're interested in bit 4 and bit 7?
Write two new functions? Or write a single function that can handle
any of these cases?

Yes I agree with you. I am against the use of c++ preprocessor to
define globals (partly because I read Scott Meyers). But the snippet I
was demonstrating was correct in itself (due to closure, i think.
Question satisfied by answer, and answer is to the point). Meep!

If I were to write something like this for my own use, I'd write
exactly what you suggested. But if I am quoting from another
source....and if they have a good reason for writing a macro instead of
function, then ranting is pointless.

I thought that should be obvious ;) So I wasn't off topic. Plus, if its
explicitly C, what makes it not C++? after all that page wasn't
discussing implicit void* casts to char* and like!!!

Well, C is not C++. The fact that C++ has a C-like subset does not
mean that any "good C practice" is a good C++ practice. Implicit void*
casts to char are one example. Another is the use of #define for
constants. There's absolutely no reason to do that in C++.

Well, C != C++ obviously, but C is a subset of C++. Just because you
are using a C++ compiler shouldn't mean you must use all the WMDs that
C++ provides. Lets use some polymorphism to relate C and C++, maybe the
most crude way to represent it is this:

class C++ : public C {
// insert stroustrupism here
http://jun.artcompsci.org/miscs/C++_legend.html
// override structs, unions, implicit void* conversions.....
};

so what does polymorphism tell you? if you derive from a base class,
there is an "is-a" relationship between the base class and derived
class. So basically C++ is a type of C. (That is also true for most
compilers, they convert C++ code to C and then use a C compiler to
create an executable.)

Does that mean anywhere you can use C you can also use C++? Sure you
can! Does that mean C++ is C? Open question. Because years of
conditioning by books, professors, and crappy recruiters looking for
"C++ Professionals" has skewed the answer in favor of "no".
Nobody said it was off-topic. Just lousy advice.
Meep!

haha. "Quien en tiempo huye, en tiempo acude."

Vad sa du?

translates into english as "He that fights and runs away, lives to
fight another day."

[Bo Persson]

"Luke Meyers" <n.***********@gmail.com> skrev i meddelandet
news:11**********************@g44g2000cwa.googlegr oups.com...

Shark wrote:

* Use #defines and bit masks. This is a highly portable method and
is
the one that should be used.
Portable, sure. Type-safe, no. Maintainable, no. Recommendable,
absolutely not.

This is what const is for.

const unsigned char BIT3 = ...

#define BIT3 (0x1<< 3)

So you're starting counting at 0? I love zero-indexing as much as
the
next fella, but that's not a reasonable convention when speaking in
terms of ordinal numbers. The rightmost bit is the first bit, not
the
zeroth bit.

Or it might be the last bit, on some hardware. So much for portability
of bits!

The bit pattern you've produced is 00001000. Surely we
can all agree that's the *fourth* bit?

Unless it's the 60th or 61st bit, counting from the left. :-)
Bo Persson

[Marcus Kwok]

Shark <cp*******@yahoo.com> wrote:

Well, C != C++ obviously, but C is a subset of C++. Just because you
are using a C++ compiler shouldn't mean you must use all the WMDs that
C++ provides. Lets use some polymorphism to relate C and C++, maybe the
most crude way to represent it is this:

class C++ : public C {
// insert stroustrupism here
http://jun.artcompsci.org/miscs/C++_legend.html
Of course, he never said this.
http://public.research.att.com/~bs/bs_faq.html#IEEE
// override structs, unions, implicit void* conversions.....
};

--
Marcus Kwok

[Shark]

Marcus Kwok wrote:

Shark <cp*******@yahoo.com> wrote:

Well, C != C++ obviously, but C is a subset of C++. Just because you
are using a C++ compiler shouldn't mean you must use all the WMDs that
C++ provides. Lets use some polymorphism to relate C and C++, maybe the
most crude way to represent it is this:

class C++ : public C {
// insert stroustrupism here
http://jun.artcompsci.org/miscs/C++_legend.html
Of course, he never said this.
http://public.research.att.com/~bs/bs_faq.html#IEEE

And he was bashed in comp.lang.c for pretending that the Fake January
interview was somehow related to "The Real IEEE Interview"
http://groups.google.com/group/comp....c4dc4844f688b3

doesn't "legend" in "C++_legend.html" tell you something?

// override structs, unions, implicit void* conversions.....
};

--
Marcus Kwok

[Marcus Kwok]

Shark <cp*******@yahoo.com> wrote:

> // insert stroustrupism here
> http://jun.artcompsci.org/miscs/C++_legend.html

Marcus Kwok wrote: Of course, he never said this.
http://public.research.att.com/~bs/bs_faq.html#IEEE

Shark <cp*******@yahoo.com> wrote: And he was bashed in comp.lang.c for pretending that the Fake January
interview was somehow related to "The Real IEEE Interview"
http://groups.google.com/group/comp....c4dc4844f688b3
The only "bashing" I saw was for posting a C++ article in a C newsgroup.
doesn't "legend" in "C++_legend.html" tell you something?

Of course, which is why I felt the need to clarify; others may not have
picked up on the subtlety. When something is called a "<insert
someone's name>-ism", it implies that it is attributable to that person.

--
Marcus Kwok

[Luke Meyers]

Shark wrote:

Yes, but the point is that it's just silly to hard-code '3' into the
function. What happens when you're interested in bit 4 and bit 7?
Write two new functions? Or write a single function that can handle
any of these cases?

Yes I agree with you. I am against the use of c++ preprocessor to
define globals (partly because I read Scott Meyers). But the snippet I
was demonstrating was correct in itself (due to closure, i think.
Question satisfied by answer, and answer is to the point). Meep!

Don't know when to quit, do you? (Nor do I, it seems...)

The snippet was correct and solved the immediate problem. However, it
was a lousy solution to the problem because it was excessively
specific, and provided no benefit in exchange for its rigidity. It's
just bad.
If I were to write something like this for my own use, I'd write
exactly what you suggested. But if I am quoting from another
source....and if they have a good reason for writing a macro instead of
function, then ranting is pointless.
It defined a macro, then used the macro in a function. I think you're
getting confused, because there are two issues:

* In C++, it's dumb to use #define for constants, because const is
better.
* In both C and C++, it's dumb to write a function like
"set3rdBit(unsigned char)" rather than "setNthBit(int, unsigned char)."
That has nothing to do with C vs. C++, embedded vs. not, etc. It's
just an idiotic programming practice.
Well, C != C++ obviously, but C is a subset of C++.
No, it's not. C++ has a C-like subset. It's different.
Just because you
are using a C++ compiler shouldn't mean you must use all the WMDs that
C++ provides.
No, but good C code can be bad C++ code. Same code, different context,
yes it really does make a difference.
Lets use some polymorphism to relate C and C++
Please let's not.
Does that mean anywhere you can use C you can also use C++? Sure you
can!
In most cases, a C++ compiler will compile valid C code. But the
matter at hand is not syntactic correctness, but good programming
practice. C++ allows much more effective practices than the
best-of-breed C practices. The bar is higher, so anything which only
comes as high as the bar for C is substantially sub-par in C++.
Does that mean C++ is C? Open question.
Not really. No more so that C++ is arithmetic. Sure, it incorporates
arithmetic. But if all you do is add, subtract, multiply, and divide,
you're kind of missing the point.
Because years of
conditioning by books, professors, and crappy recruiters looking for
"C++ Professionals" has skewed the answer in favor of "no".
Or the fact that, objectively, C++ isn't C.
translates into english as "He that fights and runs away, lives to
fight another day."

Still haven't seen the back of you. ;)

Luke

[Shark]

Luke Meyers wrote:

Shark wrote:

Lets use some polymorphism to relate C and C++
Please let's not.

Haha, it seems you are evading this issue instead of tackling it. You
don't like using polymorphism here, do you? Because it seems counter
intuitive.

If you can use polymorphism to say:

class mammals : public animals {
};

then why can't we say:

class C++ : public C {
//overload structs unions, crap
// add stroustrup conspiracy
};

Does that mean anywhere you can use C you can also use C++? Sure you
can!

Does that mean C++ is C? Open question.

Not really. No more so that C++ is arithmetic. Sure, it incorporates
arithmetic. But if all you do is add, subtract, multiply, and divide,
you're kind of missing the point.

What is the point exactly? That C++ is not C and vice versa?

Although comparing C++ and Arithmetic is an extreme example it can
still be treated with multiple inheritance

public C : public Arithmetic, public Blah1, public Blah2...... {
//define atithmetic symbols
//override some blah1 stuff
//override some blah2 stuff
...
...
};

and

public C++ : public C {
//override some C stuff
//add b.s. crap
};

So C++ indirectly inherits from Arithmetic. What is the problem? Why
shouldn't we use polymorphism to relate C++ and C?
Still haven't seen the back of you. ;)

Its called guerilla warfare :)

[Luke Meyers]

Shark wrote:

Luke Meyers wrote:

Shark wrote:

Lets use some polymorphism to relate C and C++
Please let's not.

Haha, it seems you are evading this issue instead of tackling it. You
don't like using polymorphism here, do you? Because it seems counter
intuitive.

No, your point is plenty obvious, it just doesn't mean what you want it
to mean. Polymorphism in this case (as in general) just means that C++
is (more or less) USABLE-AS C. In the same sense that a laptop
computer is usable-as a paperweight. You can use it that way, but
you're kind of missing the point if you do, and would be out of line to
recommend it to someone asking how best to use their laptop computer.

How many more cute analogies do you need? There is no reason to use
#define for symbolic constants in C++, because const is equal or better
in every way. Advocating anything else indicates that you are
ill-informed, irresponsible, or simply stubborn.
What is the point exactly? That C++ is not C and vice versa?
YES. C is certainly not C++. C++ has a C-like subset, but it is a
language unto itself, and as with any language there are certain idioms
which represent best practice developed through years of experience,
and others which are useless, bad, or dangerous. Certain "good C"
idioms are bad in C++, for a variety of reasons.
So C++ indirectly inherits from Arithmetic. What is the problem? Why
shouldn't we use polymorphism to relate C++ and C?

Because it's irrelevant to do so? Even if we accept it as true, it
doesn't support your point in any way. And, incidentally,
"inheritance" and "polymorphism" are not synonyms.

Luke

[JustBoo]

On 24 Jan 2006 22:50:04 -0800, "Luke Meyers" <n.***********@gmail.com>
wrote:

How many more cute analogies do you need? There is no reason to use
#define for symbolic constants in C++, because const is equal or better
in every way. Advocating anything else indicates that you are
ill-informed, irresponsible, or simply stubborn.

Just wondering. Does using const vars take storage? IOW, use memory
during runtime? Do #defines take storage? I believe #defines do not
take storage during runtime. Well, to pre-split a hair, other than in
the "code segment." Note the quotes. :-)

Thanks.

"There is no such thing as a good tax." - Winston Churchill

[Luke Meyers]

JustBoo wrote:

Just wondering. Does using const vars take storage? IOW, use memory
during runtime? Do #defines take storage? I believe #defines do not
take storage during runtime. Well, to pre-split a hair, other than in
the "code segment." Note the quotes. :-)

Precisely what happens depends on the compiler. Any reasonable
compiler would produce no increased overhead for using a const versus
using a literal (which is what a #define constant amounts to by the
time the compiler sees it). Const data lives in a separate section in
memory from other storage types.

Remember, even a numeric literal has to be stored somewhere.

Luke

[JustBoo]

On 25 Jan 2006 13:29:02 -0800, "Luke Meyers" <n.***********@gmail.com>
wrote:

Precisely what happens depends on the compiler. Any reasonable
compiler would produce no increased overhead for using a const versus
using a literal (which is what a #define constant amounts to by the
time the compiler sees it). Const data lives in a separate section in
memory from other storage types.

Remember, even a numeric literal has to be stored somewhere.
Luke

Interesting. So in a conformant compiler the same amount of storage
(or approximate storage) would be taken by either a #define or a const
var?

[Ben Pope]

JustBoo wrote:

On 25 Jan 2006 13:29:02 -0800, "Luke Meyers" <n.***********@gmail.com>
wrote:

Precisely what happens depends on the compiler. Any reasonable
compiler would produce no increased overhead for using a const versus
using a literal (which is what a #define constant amounts to by the
time the compiler sees it). Const data lives in a separate section in
memory from other storage types.

Remember, even a numeric literal has to be stored somewhere.
Luke

Interesting. So in a conformant compiler the same amount of storage
(or approximate storage) would be taken by either a #define or a const
var?

Well... you have to stick the number somewhere. You could point to it,
but that's probably at least as big as the number itself.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Jerry Coffin]

JustBoo wrote:

[ ... ]

Interesting. So in a conformant compiler the same amount of storage
(or approximate storage) would be taken by either a #define or a const
var?

As long as you only use the const variable in ways that literals could
be used, most compilers won't allocate any memory for it. If you do
something that requires it to have an address (e.g. take its address or
pass it by reference) then the compiler won't normally have any choice
but to allocate some memory for it.

--
Later,
Jerry.

[davidrubin]

FYI, the third bit *always* means the third bit from the right at
position 2.