Separate compilation and access to small integer data in other programs

[Fred K]

On 11/26/2012 5:14 PM, Keith Thompson wrote: > Ben Bacarisse <[email protected]> writes: > [...] >> One of the most constant things in C is a function. Can you use >> >> int constant_one() { return 42; } >> >> in place of >> >> const int constant_one = 42; >> >> ? Just a thought. >> >> <snip>> > And if you define it as "inline", it probably won't generate any > more code than a const-qualified object declaration (or an enum). The objective (as I understood it) was to make the value accessible to a module that would not require recompilation if the value were to change. There's no theoretical barrier to link-time inlining, but my impression is that it's fairlybleeding-edge stuff. Summing up, the thread has touched on three ways of making the value accessible: 0) #define it, and #include wherever needed. Pro: Simple, potential for constant expression. Con: Must recompile "everything" if value changes. 1) Use a `const'-qualified variable, and #include an `extern' declaration. Pro: Minimizes recompilation. Con: No chance for constant expression, `const' variable may be vulnerable to change at run-time. 2) Use a function returning the value, #include function's declaration. Pro: Minimizes recompilation, makes run-time change very unlikely, allows non-constant initialization. Con: No chance for constant expression.

Why wouldn't this work:

Module A:
----------------
const int ival=42;

int getIval() {return ival;}


Module B:
----------------
#include "ModuleA.h" /* declares getIval() */

void myFunction() {
const int ival = getIval();

}

 

[Eric Sosman]

On 11/26/2012 5:14 PM, Keith Thompson wrote: > Ben Bacarisse <[email protected]> writes: > [...] >> One of the most constant things in C is a function. Can you use >> >> int constant_one() { return 42; } >> >> in place of >> >> const int constant_one = 42; >> >> ? Just a thought. >> >> <snip> > > And if you define it as "inline", it probably won't generate any > more code than a const-qualified object declaration (or an enum). The objective (as I understood it) was to make the value accessible to a module that would not require recompilation if the value were to change. There's no theoretical barrier to link-time inlining, but my impression is that it's fairly bleeding-edge stuff. Summing up, the thread has touched on three ways of making the value accessible: 0) #define it, and #include wherever needed. Pro: Simple, potential for constant expression. Con: Must recompile "everything" if value changes. 1) Use a `const'-qualified variable, and #include an `extern' declaration. P

ro: Minimizes recompilation. Con: No chance for constant expression, `const' variable may be vulnerable to change at run-time. 2) Use a function returning the value, #include function's declaration. Pro: Minimizes recompilation, makes run-time change very unlikely, allows non-constant initialization. Con: No chance for constant expression.

Nice quoting style ...

Why wouldn't this work:

Module A:
----------------
const int ival=42;

int getIval() {return ival;}


Module B:
----------------
#include "ModuleA.h" /* declares getIval() */

void myFunction() {
const int ival = getIval();

}

It would work just fine: It's a hybrid of methods (1) and (2),
with all the disadvantages of both in one convenient package. (It
could be made pure (2) by adding a `static' to Module A.)