Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #5840 > unrolled thread

a doubt about c

Back to article view | Back to comp.lang.c

Contents

  a doubt about c Ya Shou <zxyzxy12321@gmail.com> - 2011-06-11 06:11 -0700
    Re: a doubt about c James Kuyper <jameskuyper@verizon.net> - 2011-06-11 09:36 -0400
    Re: a doubt about c Angel <angel+news@spamcop.net> - 2011-06-11 14:37 +0000
      Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 11:55 -0700
        Re: a doubt about c Angel <angel+news@spamcop.net> - 2011-06-11 20:41 +0000
          Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 08:58 +1200
            Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 17:09 -0500
            Re: a doubt about c Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-11 18:25 -0400
              Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 11:43 +1200
              Re: a doubt about c Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-12 05:38 -0700
                Re: a doubt about c Roberto Waltman <usenet@rwaltman.com> - 2011-06-12 10:12 -0400
                  Re: a doubt about c Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-12 10:59 -0400
                    Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-15 17:07 +0100
                  Re: a doubt about c Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-12 11:33 -0700
                  Re: a doubt about c James Kuyper <jameskuyper@verizon.net> - 2011-06-15 09:53 -0400
                  Re: a doubt about c Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-16 18:46 +0100
            Re: a doubt about c DSF <notavalid@address.here> - 2011-06-11 18:53 -0500
              Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 16:18 -0700
                Re: a doubt about c Stephen Sprunk <stephen@sprunk.org> - 2011-06-11 21:13 -0500
                  Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 14:56 +1200
                  Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 20:24 -0700
                  Re: a doubt about c Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-12 08:10 -0400
              Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 11:49 +1200
          Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 15:36 -0700
        Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-12 00:23 +0100
          Re: a doubt about c Seebs <usenet-nospam@seebs.net> - 2011-06-13 14:39 +0000
            Re: a doubt about c Squeamizh <squeamz@hotmail.com> - 2011-06-15 15:44 -0700
              Re: a doubt about c Geoff <geoff@invalid.invalid> - 2011-06-15 19:57 -0700
                Re: a doubt about c "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-16 18:39 +0100
                  Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-17 15:39 +0100
                    Re: a doubt about c Willem <willem@toad.stack.nl> - 2011-06-17 14:49 +0000
                      Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-17 09:14 -0600
                      Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-17 12:00 -0500
                    Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-17 11:08 -0500
                      Re: [OT] Doubt vs. question. (Re: a doubt about c) Shao Miller <sha0.miller@gmail.com> - 2011-06-17 13:00 -0500
                        Re: [OT] Doubt vs. question. (Re: a doubt about c) Shao Miller <sha0.miller@gmail.com> - 2011-06-22 19:01 -0500
                    Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-17 09:14 -0600
                    Re: a doubt about c Seebs <usenet-nospam@seebs.net> - 2011-06-17 22:16 +0000
                    Re: a doubt about c "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-18 02:24 +0100
        Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-11 23:09 -0600
        [OT] Doubt vs. question.  (Re: a doubt about c) Roberto Waltman <usenet@rwaltman.com> - 2011-06-12 10:05 -0400
          Re: [OT] Doubt vs. question.  (Re: a doubt about c) Keith Thompson <kst-u@mib.org> - 2011-06-12 11:22 -0700
            Re: [OT] Doubt vs. question.  (Re: a doubt about c) Ben Pfaff <blp@cs.stanford.edu> - 2011-06-12 11:44 -0700
          Re: [OT] Doubt vs. question.  (Re: a doubt about c) Ralph Spitzner <rasp@spitzner.org> - 2011-06-13 11:31 +0200
            Re: [OT] Doubt vs. question.  (Re: a doubt about c) James Kuyper <jameskuyper@verizon.net> - 2011-06-15 10:03 -0400
              Re: [OT] Doubt vs. question. (Re: a doubt about c) Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-17 07:52 +0100
              Re: [OT] Doubt vs. question.  (Re: a doubt about c) Michael Press <rubrum@pacbell.net> - 2011-06-19 00:41 -0700
                Re: [OT] Doubt vs. question.  (Re: a doubt about c) James Kuyper <jameskuyper@verizon.net> - 2011-06-19 07:04 -0400
                  Re: [OT] Doubt vs. question.  (Re: a doubt about c) Bill Waddington <william.waddington@beezmo.com> - 2011-06-23 11:03 -0700
    Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 11:23 -0500
      Re: a doubt about c pete <pfiland@mindspring.com> - 2011-06-11 13:56 -0400
        Re: a doubt about c "dr.oktopus" <blindwilly@freeonline.zzn.com> - 2011-06-11 12:53 -0700
          Re: a doubt about c Lew Pitcher <lpitcher@teksavvy.com> - 2011-06-11 16:01 -0400
          Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 13:07 -0700
          Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-11 14:13 -0600
            Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-11 23:31 +0100
              Re: a doubt about c pete <pfiland@mindspring.com> - 2011-06-11 20:07 -0400
              Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-11 23:05 -0600
        Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 16:42 -0500
          Re: a doubt about c "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-06-11 14:23 -0700
            Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 17:27 -0500
              Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 15:42 -0700
    Re: a doubt about c Seebs <usenet-nospam@seebs.net> - 2011-06-13 14:39 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#5840 — a doubt about c

Hello, friends.

I read some open source c program code, found a problem that let me doubt.
All those programs are using macros to define constants, and did not use an enum to achieve, but I think in the enumeration constants is very convenient.
Enumeration defines constants used in c++, but not seen any in c, why?

Thank you.

---- ---- ---- ----
Ya Shou (@54c3)
54c3.blogspot.com

[toc] | [next] | [standalone]

#5841

On 06/11/2011 09:11 AM, Ya Shou wrote:
> Hello, friends.
> 
> I read some open source c program code, found a problem that let me doubt.
> All those programs are using macros to define constants, and did not use an enum to achieve, but I think in the enumeration constants is very convenient.
> Enumeration defines constants used in c++, but not seen any in c, why?

This is mostly a cultural thing; it has little to do with any
differences between the way the two languages work. There are definite
advantages to using enumeration constants over macros, but most of those
advantages apply equally well in both languages. However, those
advantages are also relatively minor, which is why it's still
commonplace to use macros instead.

Enumeration constants have the type of the enumeration in C++, whereas
they always have a type of 'int' in C. Because that affects overload
resolution and template instantiation, that can be an important
difference in C++, whereas if C adopted such a rule, it wouldn't make
much difference.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#5842

On 2011-06-11, Ya Shou <zxyzxy12321@gmail.com> wrote:
> Hello, friends.
>
> I read some open source c program code, found a problem that let me doubt.
> All those programs are using macros to define constants, and did not use
> an enum to achieve, but I think in the enumeration constants is very
> convenient.

There are some advantages of using enums over #defines in C (such as
allowing compilers to do some additional checks) but unlike C++, the
advantages in C are fairly minor.

> Enumeration defines constants used in c++, but not seen any in c, why?

It's mainly historical. Enums were originally not a part of the C
language when K&R designed it; they were first added in C89. Many
sources still use #defines over enums, and both forms are acceptable
as in C there is functionally very little difference between them.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#5847

Angel <angel+news@spamcop.net> writes:
> On 2011-06-11, Ya Shou <zxyzxy12321@gmail.com> wrote:
[...]
>> Enumeration defines constants used in c++, but not seen any in c, why?
>
> It's mainly historical. Enums were originally not a part of the C
> language when K&R designed it; they were first added in C89. Many
> sources still use #defines over enums, and both forms are acceptable
> as in C there is functionally very little difference between them.

Enums are older than that.  If I recall correctly, they were added
shortly after K&R1, which was published in 1978.

One drawback of enums is that they're only of type int; you can't use
them to define constants of other types, including floating-point types.

Arguably using an enum to define a single constant:

    enum { max = 1000 };

is an abuse of the feature, which is intended to be used to define a
group of closely related constants.  Of course that stop me from using
it that way.

What I'd really like to see is for C to adopt C++'s feature, where
a const object of numeric type whose initializer is a constant
expression can be used as a constant:

    const int max = 1000;
    const double pi = 3.14159265358979;

But it's probably too late to add that to C201X.

(Incidentally, the word "doubt" is not synonymous with "question",
at least not in most dialects of English.  A "doubt" generally
implies that you disbelieve something.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5854

On 2011-06-11, Keith Thompson <kst-u@mib.org> wrote:
> Angel <angel+news@spamcop.net> writes:
>> On 2011-06-11, Ya Shou <zxyzxy12321@gmail.com> wrote:
> [...]
>>> Enumeration defines constants used in c++, but not seen any in c, why?
>>
>> It's mainly historical. Enums were originally not a part of the C
>> language when K&R designed it; they were first added in C89. Many
>> sources still use #defines over enums, and both forms are acceptable
>> as in C there is functionally very little difference between them.
>
> Enums are older than that.  If I recall correctly, they were added
> shortly after K&R1, which was published in 1978.

I was going by Wikipedia, which claims it was first introduced by ANSI.
But it is quite possible that you are right. I was only five back then
so I don't remember 1978 too well. ;-)

> One drawback of enums is that they're only of type int; you can't use
> them to define constants of other types, including floating-point types.

Very true.

> Arguably using an enum to define a single constant:
>
>     enum { max = 1000 };
>
> is an abuse of the feature, which is intended to be used to define a
> group of closely related constants.  Of course that stop me from using
> it that way.

Yeah, I tend to use enums to define groups of closely related constants,
like the byte offsets in my program to parse Infinity Engine files, which
looks like this:

// Constants to help parse header blocks of *.itm files v1 and v1.1.
enum item_v1
{
        itm_v1_signature                        = 0x0000,
        itm_v1_version                          = 0x0004,
        itm_v1_generic_name                     = 0x0008,
        itm_v1_specific_name			= 0x000c,
[...]
        itm_v1_size                             = 0x0072,
};

That replaces that ugly, non-portable packed structure I first used.

> What I'd really like to see is for C to adopt C++'s feature, where
> a const object of numeric type whose initializer is a constant
> expression can be used as a constant:
>
>     const int max = 1000;
>     const double pi = 3.14159265358979;
>
> But it's probably too late to add that to C201X.

Yeah, #defines and macros have their place, but this seems like a much
more natural way to define a numerical constant to me.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#5856

On 06/12/11 08:41 AM, Angel wrote:
> On 2011-06-11, Keith Thompson<kst-u@mib.org>  wrote:
>
>> What I'd really like to see is for C to adopt C++'s feature, where
>> a const object of numeric type whose initializer is a constant
>> expression can be used as a constant:
>>
>>      const int max = 1000;
>>      const double pi = 3.14159265358979;
>>
>> But it's probably too late to add that to C201X.
>
> Yeah, #defines and macros have their place, but this seems like a much
> more natural way to define a numerical constant to me.

The place for #define constants is the dustbin of history!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5858

On 6/11/2011 3:58 PM, Ian Collins wrote:
> On 06/12/11 08:41 AM, Angel wrote:
>> On 2011-06-11, Keith Thompson<kst-u@mib.org> wrote:
>>
>>> What I'd really like to see is for C to adopt C++'s feature, where
>>> a const object of numeric type whose initializer is a constant
>>> expression can be used as a constant:
>>>
>>> const int max = 1000;
>>> const double pi = 3.14159265358979;
>>>
>>> But it's probably too late to add that to C201X.
>>
>> Yeah, #defines and macros have their place, but this seems like a much
>> more natural way to define a numerical constant to me.
>
> The place for #define constants is the dustbin of history!
>

So then what happens to '#if'?  Does it get stuck with numbers that 
don't have an associated, meaningful name?

[toc] | [prev] | [next] | [standalone]

#5862

On 6/11/2011 4:58 PM, Ian Collins wrote:
>
> The place for #define constants is the dustbin of history!

     I guess you feel the same way about #if?

     (Not poking fun at you, really.  Various deep thinkers are
of the opinion that the entire preprocessor belongs in the
dustbin, not just the macros; perhaps you're at least partially
allied with them.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#5870

On 06/12/11 10:25 AM, Eric Sosman wrote:
> On 6/11/2011 4:58 PM, Ian Collins wrote:
>>
>> The place for #define constants is the dustbin of history!
>
>       I guess you feel the same way about #if?

#define constants that are used by the preprocessor live in a different 
realm.

>       (Not poking fun at you, really.  Various deep thinkers are
> of the opinion that the entire preprocessor belongs in the
> dustbin, not just the macros; perhaps you're at least partially
> allied with them.)

Well yes, that would be nice!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5901

On Jun 11, 11:25 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 6/11/2011 4:58 PM, Ian Collins wrote:
>
>
>
> > The place for #define constants is the dustbin of history!
>
>      I guess you feel the same way about #if?
>
>      (Not poking fun at you, really.  Various deep thinkers are
> of the opinion that the entire preprocessor belongs in the
> dustbin, not just the macros; perhaps you're at least partially
> allied with them.)

C++ still uses the preprocessor. What is the alternative to #include?
Or #if?

[toc] | [prev] | [next] | [standalone]

#5905

Nick Keighley  wrote:
>C++ still uses the preprocessor. What is the alternative to #include?

The "using stuff-from-other-module" directives as implemented in
several other languages

>Or #if?

   if (expression that evaluates to zero at compile time)
   {
        non reachable code deleted by the compiler
   }

[toc] | [prev] | [next] | [standalone]

#5907

On 6/12/2011 10:12 AM, Roberto Waltman wrote:
> Nick Keighley  wrote:
>> C++ still uses the preprocessor. What is the alternative to #include?
>
> The "using stuff-from-other-module" directives as implemented in
> several other languages
>
>> Or #if?
>
>     if (expression that evaluates to zero at compile time)
>     {
>          non reachable code deleted by the compiler
>     }

     C's preprocessor is, of course, capable of things that cannot
be done this way, for instance

	#if INT_MAX >= 1000000
	    typedef int Million;
	#else
	    typedef long Million;
	#endif

or

	struct ByLightning {
	    double toil;
	    double trouble;
	    short shrift;
	    short snort;
	    #if DEBUG_LEVEL > 2
	        char debug_buff[1024];
	    #endif
	};

     Over the years I've seen praise for the preprocessor's ability
to do this sort of thing, and sneers at C for needing preprocessor
magic to work around its weaknesses.  I'm pretty much as "C is what
it is; get over it" sort of guy, but some are less forgiving.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#6112

On Sun, 12 Jun 2011 10:59:25 -0400, Eric Sosman wrote:

>>> Or #if?
>>
>>     if (expression that evaluates to zero at compile time)
>>     {
>>          non reachable code deleted by the compiler
>>     }
> 
>      C's preprocessor is, of course, capable of things that cannot
> be done this way, for instance
> 
> 	#if INT_MAX >= 1000000
> 	    typedef int Million;
> 	#else
> 	    typedef long Million;
> 	#endif
> 
> or
> 
> 	struct ByLightning {
> 	    double toil;
> 	    double trouble;
> 	    short shrift;
> 	    short snort;
> 	    #if DEBUG_LEVEL > 2
> 	        char debug_buff[1024];
> 	    #endif
> 	};

In C++, both of these examples could be done using templates, albeit
somewhat more verbosely.

One situation which can't be handled (entirely) by templates is:

	struct Struct {
		int foo;
		int bar;
	};

	enum Fields {
		foo,
		bar
	};

	struct StructField {
		int Struct::*ptr;
		int id;
		const char* name;
		StructField(int Struct::*ptr, int id, const char* name)
			: ptr(ptr), id(id), name(name) {}
	};

	StructField f(&Struct::foo, foo, "foo");
	StructField b(&Struct::bar, bar, "bar");
	// Using the preprocessor could avoid the redundant redundancy:
	// STRUCT_FIELD(f, foo);

[toc] | [prev] | [next] | [standalone]

#5914

On Jun 12, 3:12 pm, Roberto Waltman <use...@rwaltman.com> wrote:
> Nick Keighley  wrote:
> >C++ still uses the preprocessor. What is the alternative to #include?
>
> The "using stuff-from-other-module" directives as implemented in
> several other languages
>
> >Or #if?
>
>    if (expression that evaluates to zero at compile time)
>    {
>         non reachable code deleted by the compiler
>    }

yet C++ that has added many things to a C base hasn't yet gone this
far. (I have to confess I thought #include was pretty ikky the first
time I met it)

[toc] | [prev] | [next] | [standalone]

#6105

On 06/12/2011 10:12 AM, Roberto Waltman wrote:
> Nick Keighley  wrote:
>> C++ still uses the preprocessor. What is the alternative to #include?
> 
> The "using stuff-from-other-module" directives as implemented in
> several other languages

Which C++ doesn't have.

>> Or #if?
> 
>    if (expression that evaluates to zero at compile time)
>    {
>         non reachable code deleted by the compiler
>    }

One of the primary uses of #if in C++ code is to control whether or not
code is actually included that would violate a diagnosable rule if the
condition of the #if were false. In C++, as currently defined, the code
which you label as "unreachable" is not required to be "deleted by the
compiler", except insofar as that deletion is covered by the as-if rule.
That rule doesn't allow the compiler to ignore violations of diagnosable
rules. If the "unreachable" code contains such violations, it must still
generate at least one diagnostic message, and it is still permitted to
refuse to translate such code, and in most cases, typical
implementations of C++ will do so.

Your suggested alternative also creates a scope not present in the
corresponding #if; this will often cause problems as a replacement for a
#if. For instance, if the if-condition is true, any identifiers declared
or defined within the if-block will have their scope restricted to that
block. This is incompatible with many uses of #if, including the example
that Eric Sosman gave.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#6169

Roberto Waltman <usenet@rwaltman.com> writes:

> Nick Keighley  wrote:
>>C++ still uses the preprocessor. What is the alternative to #include?
>
> The "using stuff-from-other-module" directives as implemented in
> several other languages
>
>>Or #if?
>
>    if (expression that evaluates to zero at compile time)
>    {
>         non reachable code deleted by the compiler
>    }

Like this you mean:

#if SEPARATE_FILE
#include "dostuff.c"
#else
int do_stuff(char *fred {
    return strlen(fred)*3;
}
#endif
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#5867

On Sun, 12 Jun 2011 08:58:36 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>On 06/12/11 08:41 AM, Angel wrote:
>> On 2011-06-11, Keith Thompson<kst-u@mib.org>  wrote:
>>
>>> What I'd really like to see is for C to adopt C++'s feature, where
>>> a const object of numeric type whose initializer is a constant
>>> expression can be used as a constant:
>>>
>>>      const int max = 1000;
>>>      const double pi = 3.14159265358979;
>>>
>>> But it's probably too late to add that to C201X.
>>
>> Yeah, #defines and macros have their place, but this seems like a much
>> more natural way to define a numerical constant to me.
>
>The place for #define constants is the dustbin of history!

  May I ask why you feel that way?  #define constants certainly have a
potential performance benefit over a const variable.  The use of a
#define constant is often replaced with an immediate value, whereas a
const variable is likely to be stored in a static memory pool which is
often part of the program itself.  This leaves the potential for
slower execution and a larger program size.

DSF

[toc] | [prev] | [next] | [standalone]

#5868

DSF <notavalid@address.here> writes:
> On Sun, 12 Jun 2011 08:58:36 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:
>>On 06/12/11 08:41 AM, Angel wrote:
>>> On 2011-06-11, Keith Thompson<kst-u@mib.org>  wrote:
>>>
>>>> What I'd really like to see is for C to adopt C++'s feature, where
>>>> a const object of numeric type whose initializer is a constant
>>>> expression can be used as a constant:
>>>>
>>>>      const int max = 1000;
>>>>      const double pi = 3.14159265358979;
>>>>
>>>> But it's probably too late to add that to C201X.
>>>
>>> Yeah, #defines and macros have their place, but this seems like a much
>>> more natural way to define a numerical constant to me.
>>
>>The place for #define constants is the dustbin of history!
>
>   May I ask why you feel that way?  #define constants certainly have a
> potential performance benefit over a const variable.  The use of a
> #define constant is often replaced with an immediate value, whereas a
> const variable is likely to be stored in a static memory pool which is
> often part of the program itself.  This leaves the potential for
> slower execution and a larger program size.

If a const object's initialization is a constant expression, any
decent optimizing compiler will replace any reference to the object
with its value (unless fetching it from memory is actually faster
on the system in question).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5876

On 11-Jun-11 18:18, Keith Thompson wrote:
> DSF <notavalid@address.here> writes:
>>   May I ask why you feel that way?  #define constants certainly have a
>> potential performance benefit over a const variable.  The use of a
>> #define constant is often replaced with an immediate value, whereas a
>> const variable is likely to be stored in a static memory pool which is
>> often part of the program itself.  This leaves the potential for
>> slower execution and a larger program size.
> 
> If a const object's initialization is a constant expression, any
> decent optimizing compiler will replace any reference to the object
> with its value (unless fetching it from memory is actually faster
> on the system in question).

AFAICT, that would not be legal since some other code outside the
current compilation unit could cast away the variable's const-ness and
alter its value.  It's also not possible to eliminate the object
entirely if some code takes its address with the & operator.

If const objects were actually constant expressions in C rather than
merely read-only objects, as one might naïvely expect (and they are in
C++), that'd be a different matter.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#5877

On 06/12/11 02:13 PM, Stephen Sprunk wrote:
> On 11-Jun-11 18:18, Keith Thompson wrote:
>> DSF<notavalid@address.here>  writes:
>>>    May I ask why you feel that way?  #define constants certainly have a
>>> potential performance benefit over a const variable.  The use of a
>>> #define constant is often replaced with an immediate value, whereas a
>>> const variable is likely to be stored in a static memory pool which is
>>> often part of the program itself.  This leaves the potential for
>>> slower execution and a larger program size.
>>
>> If a const object's initialization is a constant expression, any
>> decent optimizing compiler will replace any reference to the object
>> with its value (unless fetching it from memory is actually faster
>> on the system in question).
>
> AFAICT, that would not be legal since some other code outside the
> current compilation unit could cast away the variable's const-ness and
> alter its value.  It's also not possible to eliminate the object
> entirely if some code takes its address with the&  operator.

The only way to alter the value is to take the address with the & 
operator.  How does one take the address of a macro constant?

> If const objects were actually constant expressions in C rather than
> merely read-only objects, as one might naïvely expect (and they are in
> C++), that'd be a different matter.

Both the compilers I use will place a variable declared const at a read 
only address.  So any attempt to change its value will release nasal demons.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web