Re: q for the C hackers
> ANSI C allows the implementation to store duplicate strings in the > same memory location at runtime. > I stand corrected. My claim came from a very old document. The only (draft) version of the ISO standard I have at my finger tips says it is now "unspecified". I think my argument still stands though since it is likely some compilers will not do this optimization (assuming it is still unspecified), and probably none will do it across compilation units. One more case where the allocation of a const variable is useful though is when you want to set the values at link time. You can put all these *constants* in one C file and link with the version of your choice. Especially handy for binary-only distributions. -dl -- David A. Long JumpShift, LLC [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
On Tue, 2003-08-19 at 08:46, Bob Bell wrote:
> Actually, the following is valid C99:
> const int m = 10;
> int
> foo(int n) {
> char s[n];
> char t[m];
> ...
> }
Yes, C99 supports variable sized arrays, but that's not always what you
want. They cannot be statically allocated and cannot be initialized.
Consider the following:
const int m = 10;
int buf[m];
int
foo(int n) {
char s[n] = { 0 };
char t[m];
// code
}
% gcc -std=c99 t.c -o t
t.c:2: error: variable-size type declared outside of any function
t.c: In function `foo':
t.c:5: error: variable-sized object may not be initialized
t.c:5: warning: excess elements in array initializer
t.c:5: warning: (near initialization for `s')
aaron
signature.asc
Description: This is a digitally signed message part
Re: q for the C hackers
Tom Fogal <[EMAIL PROTECTED]> writes:
> The const is purely optional; you could just as easily remember yourself that
> 'hey, i dont want to change that value in this function' and simply not do it.
> The justification i was given for such usage is that someone who is not you
> can quickly look at the function header/prototype and see, 'oh, this value is
> const, it wont change when i pass it to the function'.
> Also, supposedly it prevents you from 'forgetting' you didnt mean to change it,
> and doing so on accident. IMHO though, if you can't remember you didn't want
> to change a fqn parameter, you're functions are wy to long, or you aren't
> cut out for the programming vocation :P
(Hmm. Maybe I'm not cut out for programming...)
I must politely, but strenuously disagree. "const" is incredibly
useful.
I can think of this large class library that I had trouble using in
the past, all because the people who implemented it had a bizarre idea
of who owned what memory. Instead of being able to code to a
well-defined interface (and this involves "const"), I was told to look
at the implementation of each function/method. This was tedious,
inconsistant, and when the underlying implementation changed (and it
didoften...), I found myself debugging code into the wee hours.
In a large project, "const" is invaluable.
[snip]
> Oh yes, this is a source of much confusion. You see, C++ introduced this idea
> called a 'reference', which, for all intents and purposes is a pointer, but
> you dont have to dereference it as such. thus if i have a procedure that wants
> to change its integer parameter to 5, i could do the following in C++:
>
> void change_int(int &changeme) { changeme = 5; }
>
> C programmers would flip at such a statement - 'Youll screw everything up! That
> makes changeme have whatever is in memory location "5"! That could be
> ANYTHING!' etc etc.
> Well, thats true. In C, &changeme means 'the address of changeme'. In C++, the
> &changeme could mean EITHER 'the address of changeme' OR 'a reference to
> changeme'. I've never had a good explanation as to how one could tell which
> is meant. It seems to me that if its passed as a function parameter, it is a
> reference. Within a function, it means 'address of'. Don't quote me on that.
>
> Another CS major concurs with my interpretation, acutally.. perhaps I got it
> right...
I find this to be a bit confused...
1: In C++, if "a" is a reference to "b", then "a" is ANOTHER NAME FOR
"b". THAT'S IT. No magic here.
2: C++ references are different from Java references in that it is
not possible/legal to have a null reference. A lot of people get
hung up on this...
3: C++ references might be implemented in terms of pointers, but you
shouldn't care about this.
There you go.
--kevin
--
Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA)
cetaceannetworks.com!kclark (GnuPG ID: B280F24E)
alumni.unh.edu!kdc
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
Tom Fogal wrote: The bit about memory addresses instead of some large value is entirely correct. Practically however, this will only be better when passing a value larger than the register size of the architecture you are on. For instance, on ix86 linux, all pointers are 32-bit integers. Thus passing a constant reference to another integer still means you have to pass an integer to the function, thus saving nothing. This is commonly used when you have a large record or object. Okay, that makes sense. Fundamentally, there seems to be little difference between passing a pointer to an object, and passing the address of the variable holding that object's value. I seem to recall that there literally *is* no difference, actually -- a pointer is just the address of a variable IIRC. But I'm glad you confirmed this. The const is purely optional; you could just as easily remember yourself that 'hey, i dont want to change that value in this function' and simply not do it. The justification i was given for such usage is that someone who is not you can quickly look at the function header/prototype and see, 'oh, this value is const, it wont change when i pass it to the function'. I had forgotten about the header/prototype. Yes, it seems desirable to use 'const' in any function declaration that doesn't modify the parameters, as a way of communicating to others that the parameters will not be modified. I will get in the habit of using 'const' in function parameters. (I don't know C++, but let me take a guess at something -- that, in C++ making a passed reference a constant by using 'const' in a function declaration doesn't make any assurances that the object which the reference points to will not be modified, only that the reference itself will not change. In other words, it is much like passing a 'final' reference in Java.) Btw, a similar gain can be obtained via pointers, so C programmers aren't left out =). And this is what I am more used to seeing -- it appears that usually a function will be written to accept a pointer, rather than a value's address, even if they are the same thing. is a reference, and that this is different from the address of 'val'? I thought that this meant "the address of 'val'". Oh yes, this is a source of much confusion. You see, C++ introduced this idea called a 'reference', which, for all intents and purposes is a pointer, but you dont have to dereference it as such. I think I'm going to stay away from C++ for the moment, at least until I have a better grip on C and Objective-C. (Coming from a Java perspective, Objective-C seems a little more straightforward to me than C++, esp since it doesn't seem to have changed any of the rules of C.) Thanks again Tom and everyone. Erik ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
> Tom Fogal wrote:
>
> >>I'm just interested in hearing about whether one is more appropriate
> >>than the other in some contexts. Thanks.
> >
> >
> > Generally, I would use #defines for anything but function parameters.
> > Passing things as a constant reference (const type &val) is a good way to
> > avoid passing a large value without the overhead of actual passing it.
>
> I understand what you are saying, about passing a reference to something
> rather than passing the thing itself. My understanding is that this is
> because the value of a reference is a memory address, which is usually
> smaller than say, some large value (please correct me if this is
> incorrect). But why does it have to have "const" placed there? This
> seems like it should prevent the value from being modified in the body
> of the function somehow, but is it required or are you suggesting it as
> good practice?
The bit about memory addresses instead of some large value is entirely correct.
Practically however, this will only be better when passing a value larger than
the register size of the architecture you are on. For instance, on ix86 linux,
all pointers are 32-bit integers. Thus passing a constant reference to another
integer still means you have to pass an integer to the function, thus saving
nothing.
This is commonly used when you have a large record or object.
The const is purely optional; you could just as easily remember yourself that
'hey, i dont want to change that value in this function' and simply not do it.
The justification i was given for such usage is that someone who is not you
can quickly look at the function header/prototype and see, 'oh, this value is
const, it wont change when i pass it to the function'.
Also, supposedly it prevents you from 'forgetting' you didnt mean to change it,
and doing so on accident. IMHO though, if you can't remember you didn't want
to change a fqn parameter, you're functions are wy to long, or you aren't
cut out for the programming vocation :P
Btw, a similar gain can be obtained via pointers, so C programmers aren't
left out =).
> > Unfortunately, references do not exist in C alone (they were introduced in
> C++)
>
> I seem to be confused about the difference between references and a
> type's address. Are you saying that
>
>&val
>
> is a reference, and that this is different from the address of 'val'? I
> thought that this meant "the address of 'val'".
Oh yes, this is a source of much confusion. You see, C++ introduced this idea
called a 'reference', which, for all intents and purposes is a pointer, but
you dont have to dereference it as such. thus if i have a procedure that wants
to change its integer parameter to 5, i could do the following in C++:
void change_int(int &changeme) { changeme = 5; }
C programmers would flip at such a statement - 'Youll screw everything up! That
makes changeme have whatever is in memory location "5"! That could be
ANYTHING!' etc etc.
Well, thats true. In C, &changeme means 'the address of changeme'. In C++, the
&changeme could mean EITHER 'the address of changeme' OR 'a reference to
changeme'. I've never had a good explanation as to how one could tell which
is meant. It seems to me that if its passed as a function parameter, it is a
reference. Within a function, it means 'address of'. Don't quote me on that.
Another CS major concurs with my interpretation, acutally.. perhaps I got it
right...
In any case, when programming in C only you don't need to worry about such
unwarranted complications (although i'm a bit biased in that i dislike C++ :).
> Thanks everyone for contributing to this discussion.
np, my pleasure =)
-tom
>
> Erik
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
David Long <[EMAIL PROTECTED]> writes: > Also, for strings the C standard requires each literal > string constant to occupy unique read/write storage (in case the code > decides to rewrite part of it). ANSI C allows the implementation to store duplicate strings in the same memory location at runtime. --kevin (the compiler guy) -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
Tom Fogal <[EMAIL PROTECTED]> writes:
> the const int way stores the variable in read only memory, and thus, IMO is a
> waste of memory. Also, it would be required to do a memory lookup when
> accessing the value.
The value *might* get stored in read-only memory. The standard
doesn't require this.
[snip]
> Finally, I've never actually heard of 'const' in C. I know that it was
> introduced with C++, although i would not be surprised to see later editions
> of the C standard included it.
> It is not in K&R ('the white book'), IIRC.
Unless you're looking at the old testament, I gotta believe its in
there. "const" most certainly exists in C.
Regards,
--kevin
--
Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA)
cetaceannetworks.com!kclark (GnuPG ID: B280F24E)
alumni.unh.edu!kdc
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
On Tue, Aug 19, 2003 at 08:26:22AM -0400, Kevin D. Clark wrote: > > Normally, the former way is what you'd use. The latter construct is > > most often used, in my experience, for function parameters which you > > want to make sure are not modified by the function to which they > > belong. > > This is confused. Erik wasn't even asking about function parameters. > He just wants to use a constant in his program. I never said he was... I was merely commenting that in my experience, using a const int is most commonly used to declare parameters of a function, whereas #define'd macros are generally used for known constants. I'm not sure what's confused about that. > Like you stated in a later post, exactly *what* the compiler does for > these cases is implementation defined. Agreed. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp0.pgp Description: PGP signature
Re: q for the C hackers
Tom Fogal wrote: I'm just interested in hearing about whether one is more appropriate than the other in some contexts. Thanks. Generally, I would use #defines for anything but function parameters. Passing things as a constant reference (const type &val) is a good way to avoid passing a large value without the overhead of actual passing it. I understand what you are saying, about passing a reference to something rather than passing the thing itself. My understanding is that this is because the value of a reference is a memory address, which is usually smaller than say, some large value (please correct me if this is incorrect). But why does it have to have "const" placed there? This seems like it should prevent the value from being modified in the body of the function somehow, but is it required or are you suggesting it as good practice? Unfortunately, references do not exist in C alone (they were introduced in C++) I seem to be confused about the difference between references and a type's address. Are you saying that &val is a reference, and that this is different from the address of 'val'? I thought that this meant "the address of 'val'". Thanks everyone for contributing to this discussion. Erik ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Reply-to header, yet again (was Re: q for the C hackers)
On Tue, Aug 19, 2003 at 02:50:01AM -0400, Aaron Hope wrote: > BTW, Is there a reason why mailman isn't configured to set the > reply-to header? Yes. We've had this holy war before, and the (small) majority of list members were against reply-to. The logical argument: Setting the reply-to header changes the behavior of your mailer, such that it no longer does what it is intended to do when you use the reply function: reply to the sender. Setting the reply-to header makes it impossible for well-behaved mailers to send a private reply to the sender without manually editing the headers. Leaving it out makes it possible for well-behaved mailers to use a "list-reply" function to respond to the list, when that is what we want to do, or failing that to use the "group-reply" function, which virtually all mailers have had for centuries now. Setting reply-to also makes it impossible to respond to posters who have themselves set the reply-to header because they NEED it. That's the essence of it, but if you haven't heard enough, there's this: http://www.unicom.com/pw/reply-to-harmful.html People familiar with the argument also know about this: http://www.metasystema.org/essays/reply-to-useful.mhtml In the end, it can be shown that munging reply-to causes some users genuine damage (such as in the case of the guy who needs to set reply-to in order to receive mail), whereas not munging it merely reduces convenience for some people who have sh!tty mailers. The rest of the world shouldn't be punished for your poor choice of software... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp0.pgp Description: PGP signature
Re: q for the C hackers
> However, what is the convention in C? There seem to be two fine ways > of doing it -- using the preprocessor, or the const keyword: > > #define NUMBER_OF_UNITS 8 > > const int NUMBER_OF_UNITS = 8; > > > > I'm just interested in hearing about whether one is more appropriate > than the other in some contexts. Thanks. I would stick with defines. More modern languages have the option of effectively treating a "const" declaration as an immediate value, but I do not believe that C can. However there are times when a declaration which allocates storage is necessary, as when you need to pass a pointer to a value. Also, for strings the C standard requires each literal string constant to occupy unique read/write storage (in case the code decides to rewrite part of it). Therefore allocating a (optionally const) variable will use less storage than repeated use of a define'd string constant. Alternatively most compilers provide an option for making string constants read-only. The "const" type modifier is part of the ANSI/ISO C language standard (as is "void" and various other post K&R enhancements). -dl -- David A. Long JumpShift, LLC [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Reply-To munging (was: q for the C hackers)
On Tue, 2003-08-19 at 09:53, [EMAIL PROTECTED] wrote: > To avoid rehashing, here are the two arguments: > > Reply-To Munging Considered Harmful > http://www.unicom.com/pw/reply-to-harmful.html > > Reply-To Munging Considered Useful > http://www.metasystema.org/essays/reply-to-useful.mhtml Thank God for Evolution's 'Reply to List' option! :-) ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Reply-To munging (was: q for the C hackers)
On Tue, 19 Aug 2003, at 2:50am, [EMAIL PROTECTED] wrote: > BTW, Is there a reason why mailman isn't configured to set the reply-to > header? Some time back, the list took a vote, and more people voted "harmful" then "useful", and we went with the plurality. To avoid rehashing, here are the two arguments: Reply-To Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html Reply-To Munging Considered Useful http://www.metasystema.org/essays/reply-to-useful.mhtml -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
On Tue, Aug 19, 2003 at 09:07:23AM -0400, Kevin D. Clark <[EMAIL PROTECTED]> wrote:
Another possibility is to use enums, i.e.:
enum { BUFSIZE=512 };
char arr[BUFSIZE];
I use this frequently, and I recommend this.
One advantage of enum's is that symbolic debuggers can display the
symbolic name, instead of just the numeric value, if the data type is
right. We do this in the HP-UX kernel. It even works with bit flags.
It's nice when debugging.
--
Bob Bell <[EMAIL PROTECTED]>
-
"Windows 98: n. minor bug-fix/patch release of 32-bit extensions
and a graphical shell for a 16-bit patch to an 8-bit operating
system originally coded for a 4-bit microprocessor, written by a
2-bit company that can't stand 1 bit of competition."
-- Author unknown
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
sorry, again. Always forget to change the 'To:' to the list...
--- Forwarded Message
To: Erik Price <[EMAIL PROTECTED]>
Subject: Re: q for the C hackers
In-Reply-To: Your message of "Mon, 18 Aug 2003 20:13:05 EDT."
<[EMAIL PROTECTED]>
Date: Tue, 19 Aug 2003 09:10:42 -0400
From: Tom Fogal <[EMAIL PROTECTED]>
> When I want to define a constant value in Java, such as a magic number,
> I usually use "public static final":
>
> public static final int NUMBER_OF_UNITS = 8;
>
> However, what is the convention in C? There seem to be two fine ways
> of doing it -- using the preprocessor, or the const keyword:
>
> #define NUMBER_OF_UNITS 8
>
> const int NUMBER_OF_UNITS = 8;
>
the normal 'C' (as opposed to C++) convention is to use #defines.
the difference between the two is that the define is replaced with its value
by the C preprocessor, before any code is compiled. The actual 'text' section
of your executable/binary should be where the number '8' would show up,
although i dont think that behavior is defined by the C standard.
the const int way stores the variable in read only memory, and thus, IMO is a
waste of memory. Also, it would be required to do a memory lookup when
accessing the value.
> I'm just interested in hearing about whether one is more appropriate
> than the other in some contexts. Thanks.
Generally, I would use #defines for anything but function parameters.
Passing things as a constant reference (const type &val) is a good way to
avoid passing a large value without the overhead of actual passing it.
Unfortunately, references do not exist in C alone (they were introduced in C++)
Finally, I've never actually heard of 'const' in C. I know that it was
introduced with C++, although i would not be surprised to see later editions
of the C standard included it.
It is not in K&R ('the white book'), IIRC.
HTH,
- -tom
--- End of Forwarded Message
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
Aaron Hope <[EMAIL PROTECTED]> writes:
> On Mon, 2003-08-18 at 20:13, Erik Price wrote:
> > However, what is the convention in C? There seem to be two fine ways
> > of doing it -- using the preprocessor, or the const keyword:
> >
> > #define NUMBER_OF_UNITS 8
> >
> > const int NUMBER_OF_UNITS = 8;
>
> Generally, the more the compiler knows, the better it can do it's job,
> so I usually prefer the latter. There are still some places in C (C99
> specifically) where you you have no choice but to use macros, like array
> declarations.
Another possibility is to use enums, i.e.:
enum { BUFSIZE=512 };
char arr[BUFSIZE];
I use this frequently, and I recommend this.
> I believe that C++ const variables can be used wherever a
> simple #define can.
Well, they can be used for array initialization too.
--kevin
--
Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA)
cetaceannetworks.com!kclark (GnuPG ID: B280F24E)
alumni.unh.edu!kdc
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
On Tue, Aug 19, 2003 at 02:50:01AM -0400, Aaron Hope <[EMAIL PROTECTED]> wrote:
On Mon, 2003-08-18 at 20:13, Erik Price wrote:
> However, what is the convention in C? There seem to be two fine ways
> of doing it -- using the preprocessor, or the const keyword:
>
> #define NUMBER_OF_UNITS 8
>
> const int NUMBER_OF_UNITS = 8;
Generally, the more the compiler knows, the better it can do it's job,
so I usually prefer the latter. There are still some places in C (C99
specifically) where you you have no choice but to use macros, like array
declarations. I believe that C++ const variables can be used wherever a
simple #define can.
Actually, the following is valid C99:
const int m = 10;
int
foo(int n) {
char s[n];
char t[m];
...
}
BTW, Is there a reason why mailman isn't configured to set the
reply-to header?
Because we don't want it to. Can we not go there again? Convince
your mailer to set Mail-Followup-To, if you'd like (mutt does that).
--
Bob Bell <[EMAIL PROTECTED]>
-
"If the only tool you have is a hammer, you tend to see every
problem as a nail."
-- Abraham Maslow
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
Derek Martin <[EMAIL PROTECTED]> writes: > On Mon, Aug 18, 2003 at 08:13:05PM -0400, Erik Price wrote: > > However, what is the convention in C? There seem to be two fine > > ways of doing it -- using the preprocessor, or the const keyword: > > > > #define NUMBER_OF_UNITS 8 > > > > const int NUMBER_OF_UNITS = 8; > > Normally, the former way is what you'd use. The latter construct is > most often used, in my experience, for function parameters which you > want to make sure are not modified by the function to which they > belong. This is confused. Erik wasn't even asking about function parameters. He just wants to use a constant in his program. Sure, "const" carries some meaning when used with function parameters, but Erik wasn't asking about this. > I'm not a compiler guru, but I believe references to the #define'd > macro will cause the compiler to use immediate mode addressing, using > the value of the macro literally, requiring no additional storage > beyond what is required to store the opcode and its operands. Whereas > the second method allocates storage in the segment of memory > associated with initialized data that hangs around, so that it can > contain the constant. Like you stated in a later post, exactly *what* the compiler does for these cases is implementation defined. --kevin -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 18 Aug 2003 20:53:01 -0400 Ray Cote <[EMAIL PROTECTED]> wrote: > At 8:13 PM -0400 8/18/03, Erik Price wrote: > >However, what is the convention in C? There seem to be two fine > >ways of doing it -- using the preprocessor, or the const keyword: > > > >#define NUMBER_OF_UNITS 8 > > > >const int NUMBER_OF_UNITS = 8; > This tends to be the nicer way to do it these days. > Biggest advantage is that you get type checking with a const which > you don't get with a #define. > Been so long since I used pure C (vs C++) compilers, that I'm not > sure whether const ever made it into the C standard, or if it is > still a C++ extension. Well supported, though. Works in all the > compilers I use. The difference, in C, is that the const keyword was introduced by the ANSI 89 standard. Unlike C++, NUMBER_OF_UNITS (const int) is a variable and may even be altered. In C++, this construct would be a true constant (as Aaron mentions). - -- Jerry Feldman <[EMAIL PROTECTED]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QgoR+wA+1cUGHqkRAljfAJ0ZGX2IQ7ogou/wn6BGs7IDdacRlwCfRFUq zg4UxBnSHaWGHIY+8LLpg3k= =5VN8 -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
On Mon, 2003-08-18 at 20:13, Erik Price wrote: > However, what is the convention in C? There seem to be two fine ways > of doing it -- using the preprocessor, or the const keyword: > > #define NUMBER_OF_UNITS 8 > > const int NUMBER_OF_UNITS = 8; Generally, the more the compiler knows, the better it can do it's job, so I usually prefer the latter. There are still some places in C (C99 specifically) where you you have no choice but to use macros, like array declarations. I believe that C++ const variables can be used wherever a simple #define can. aaron BTW, Is there a reason why mailman isn't configured to set the reply-to header? signature.asc Description: This is a digitally signed message part
Re: q for the C hackers
On Mon, Aug 18, 2003 at 08:52:16PM -0400, Derek Martin wrote: > beyond what is required to store the opcode and its operands. Whereas > the second method allocates storage in the segment of memory > associated with initialized data that hangs around, so that it can > contain the constant. Er, actually, /where/ the storage is allocated depends on the scope of the definition of the variable, and quite possibly on the implementation of the compiler. It's also possible that an optimizing compiler may recognize that this variable contains a known constant, and optimize it out of existence. I think I have that right now. Hopefully people who've more experience than I with such matters will point out where I've still got it wrong. :) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp0.pgp Description: PGP signature
Re: q for the C hackers
At 8:13 PM -0400 8/18/03, Erik Price wrote: However, what is the convention in C? There seem to be two fine ways of doing it -- using the preprocessor, or the const keyword: #define NUMBER_OF_UNITS 8 const int NUMBER_OF_UNITS = 8; This tends to be the nicer way to do it these days. Biggest advantage is that you get type checking with a const which you don't get with a #define. Been so long since I used pure C (vs C++) compilers, that I'm not sure whether const ever made it into the C standard, or if it is still a C++ extension. Well supported, though. Works in all the compilers I use. --Ray -- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: q for the C hackers
On Mon, Aug 18, 2003 at 08:13:05PM -0400, Erik Price wrote: > However, what is the convention in C? There seem to be two fine > ways of doing it -- using the preprocessor, or the const keyword: > > #define NUMBER_OF_UNITS 8 > > const int NUMBER_OF_UNITS = 8; Normally, the former way is what you'd use. The latter construct is most often used, in my experience, for function parameters which you want to make sure are not modified by the function to which they belong. I'm not a compiler guru, but I believe references to the #define'd macro will cause the compiler to use immediate mode addressing, using the value of the macro literally, requiring no additional storage beyond what is required to store the opcode and its operands. Whereas the second method allocates storage in the segment of memory associated with initialized data that hangs around, so that it can contain the constant. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp0.pgp Description: PGP signature
q for the C hackers
When I want to define a constant value in Java, such as a magic number, I usually use "public static final": public static final int NUMBER_OF_UNITS = 8; However, what is the convention in C? There seem to be two fine ways of doing it -- using the preprocessor, or the const keyword: #define NUMBER_OF_UNITS 8 const int NUMBER_OF_UNITS = 8; I'm just interested in hearing about whether one is more appropriate than the other in some contexts. Thanks. Erik ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
