checking bits
Mark
how might i do this?
thanks!
Mike Wahler
"Mark" <mnba...@gmail.com> wrote in message
news:1137634698.3...@g43g2000cwa.googlegroups.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" <mkwa...@mkwahler.net> wrote in message
news:4eCzf.3733$Hd4....@newsread1.news.pas.earthlink.net...
Alternatively, there's the 'std::bitset' type
from the standard library.
-Mike
Mark
this should help anyone else who cares to know
http://www.cprogramming.com/tutorial/bitwise_operators.html
Shark
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
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
> Mark wrote:
>> alright. thanks :)
>>
>> this should help anyone else who cares to know
>> http://www.cprogramming.com/tutorial/bitwise_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
>
> 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.Aba...@comAcast.net> wrote in message
news:cLKdnQPLKKjczk3e...@comcast.com...
> Shark wrote:
>> Mark wrote:
>>> alright. thanks :)
>>>
>>> this should help anyone else who cares to know
>>> http://www.cprogramming.com/tutorial/bitwise_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
> 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
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
> * 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
> 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
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
> 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
> 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.lang.c++/browse_thread/thread/89d12baaa66af592/cecb0b3712efb881?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
> 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
> 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
> 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
> 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.luke...@gmail.com> skrev i meddelandet
news:1137969638.1...@g44g2000cwa.googlegroups.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
> 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
> Shark <cpp_...@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.lang.c/browse_thread/thread/7de485cf8c7795/c8c4dc4844f688b3
doesn't "legend" in "C++_legend.html" tell you something?
Marcus Kwok
>> > // 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 <cpp_...@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.lang.c/browse_thread/thread/7de485cf8c7795/c8c4dc4844f688b3
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
> > 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
> Shark wrote:
>
>
> 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
> 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
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
> 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
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
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
[ ... ]
> 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.
david...@warpmail.net
position 2.