Board index » cppbuilder » Re: #define auto increment

Re: #define auto increment


2003-11-24 05:22:37 AM
cppbuilder71
Hi!
Junk Mail wrote:
Quote
Just a couple of questions...I'm not sure but this is how I believe things
are working.

When I use #define x 5

When I compile all the x's get replaced by 5
Correct.
Quote
When I use const int x = 5
I'm actually reserving 4 bytes of memory with the value 5 stored in it.
Correct.
Quote
Every reference requires that the value of the x address be looked up during
run time? Correct or incorrect?
Incorrect.
const int c = 5;
int array[c]; //works, because c is a compile time constant
int i=5;
const int j=i++;
int array2[j]; //does not work, j is not a compile time constant
Now: For a compile time constant, the compiler replaces all possible
occurances of x with 5. Only when you take the address of x (which you
cannot do, if you had #defined it), then dereferencing is done at runtime:
const int c=5; //compile time constant
int i=6;
const int d=i++; //not a compile time constant
void foo(int h)
{
int x = c; //equals: "int x = 5;"
int y = d; //runtime overhead for look-up
}
Quote
By the way what is wrong with

int id = 1;

const int x1 = id++;
const int x2 = id++;
const int x3 = id++;
etc
That is ok, but it does not produce compile time constants.
Quote
As long as I have it defined in #ifndef #endif
? What do you mean? The precompiler doesn't care about "const int"s.
Oh, you mean for headers? The linker will give you "duplicate
symbol"-warnings, I guess. At least when they are not compile time
constants.
Frank
 
 

Re:Re: #define auto increment

"Thomas Maeder [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
"Junk Mail" < XXXX@XXXXX.COM >writes:

>>Unless you need these macros for preprocessing (such as conditional
>>compilation), you could use an enumeration type:
>
>I'm using them for a resource file...can I use enumerated types in a
>resource file as the ID?

I don't think so. But aren't resource header generated?
I'm generating the .rc file and the .rh file manually
 

Re:Re: #define auto increment

ok how about this
.h file
extern const int x1;
extern const int x2;
...
extern const int xn;
.cpp file
static int id = 1;
const int x1 = id++;
const int x2 = id++;
...
const int xn = id++;
That should take care of including the header file more than once...any
problem you see with using this approach?
 

{smallsort}

Re:Re: #define auto increment

In C++ this declaration takes no memory and is by default limited to only
the file in which the declaration appears:
const int x = 5;
It is usable in the source file anywhere the number 5 could be used, even at
compile time as an array dimension, so it does much of what a #define macro
does but with type checking.
If you had a declaration such as extern const int x; in advance of that
then it would be made a public symbol and would take memory.
Note that this is a C++ thing. An RC file needs a #define, not a const
declaration.
Quote
By the way what is wrong with

int id = 1;

const int x1 = id++;
const int x2 = id++;
const int x3 = id++;
etc
You could always try it and read the errors it generates.
Assuming that this is file global, outside of classes, etc, there are
problems with that. The declarations of x1, x2 and x3 are as a const, a
value known at compile time.
The problem with it is that the declaration of id is as a variable so will
be known for its value only at run time. The initialization value for the
const must be known at compile time.
Quote
As long as I have it defined in #ifndef #endif
I do not know how you mean for this to apply.
. Ed
Quote
Junk Mail wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Re: #define auto increment

Hi!
Ed Mulroy [TeamB] wrote:
Quote
In C++ this declaration takes no memory and is by default limited to only
the file in which the declaration appears:

const int x = 5;
It will take memory as soon as you start taking its address via "&x".
Quote
Note that this is a C++ thing. An RC file needs a #define, not a const
declaration.
Because it is a Microsoft invention ? ;)
I still think they do C instead of C++. Think of all the windows stuff,
it looks way too complicated to me. Even in DirectX they still want
structs to be initialised, hey don't they know constructors?
Quote
>By the way what is wrong with
>
>int id = 1;
>
>const int x1 = id++;
>const int x2 = id++;
>const int x3 = id++;
>etc


You could always try it and read the errors it generates.
None?
Quote
Assuming that this is file global, outside of classes, etc, there are
problems with that. The declarations of x1, x2 and x3 are as a const, a
value known at compile time.
Not necessarily.
Quote
The problem with it is that the declaration of id is as a variable so will
be known for its value only at run time. The initialization value for the
const must be known at compile time.
Really? I don't think so. It compiles at least with BCB5. And I think it
should compile on any conforming compiler, too. Consider:
#include <iostream>
using namespace std;
struct foo{
int i;
foo(int i_) : i(i_) { cout << "Hello World!" << endl; }
};
const foo f(4);
int main() { &f; }
I think this should compile. I think it does occupy memory. Now, how are
ints different from foo?
Frank
 

Re:Re: #define auto increment

The discussion was about using a const as an alternative to a #define for
initial values to be used in the program. It was not about taking the
address of a constant in the constructor of a structure. I see no
similarity between your class initialization code and what I was talking
about.
A const must be initialized with a literal or another const to be a const at
compile time. For example:
-------------------------------------------
C:\Lookat\temp
Quote
type temp86.cpp
#include <cstdio>
using namespace std;
int id = 1;
#if !defined XCONST
const int x1 = id++;
const int x2 = id++;
const int x3 = id++;
#else
const int x1 = 1;
const int x2 = 2;
const int x3 = 3;
#endif
int main()
{
char buf1[x1]; // line 18
char buf2[x2]; // line 19
char buf3[x3]; // line 20
for (int i = 0; i < x1 - 1; ++i)
buf1[i] = '1';
buf1[x1 - 1] = '\0';
for (int i = 0; i < x2 - 1; ++i)
buf1[i] = '1';
buf1[x2 - 1] = '\0';
for (int i = 0; i < x3 - 1; ++i)
buf1[i] = '1';
buf1[x3 - 1] = '\0';
printf("%s\n%s\n%s\n", buf1, buf2, buf3);
return 0;
}
C:\Lookat\temp
Quote
bcc32 -WCR temp86
Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland
TEMP86.CPP:
Error E2313 TEMP86.CPP 18: Constant expression required in function main()
Error E2313 TEMP86.CPP 19: Constant expression required in function main()
Error E2313 TEMP86.CPP 20: Constant expression required in function main()
*** 3 errors in Compile ***
Quote
q temp86
C:\Lookat\temp
bcc32 -WCR -DXCONST temp86
Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland
TEMP86.CPP:
Turbo Incremental Link 5.64 Copyright (c) 1997-2002 Borland
C:\Lookat\temp
Quote

-------------------------------------------
And if you build with XCONST defined and with an added -S to the left of the
file name on the command line you will then be able to look a the generated
*.asm file and see for yourself that there is not even one byte assigned to
all of the constant integers x1, x2 and x3.
. Ed
Quote
Frank Birbacher wrote in message
news:3fc1527e$ XXXX@XXXXX.COM ...
Hi!

>Ed Mulroy wrote:
>In C++ this declaration takes no memory and is by default limited to
only
>the file in which the declaration appears:
>
>const int x = 5;

It will take memory as soon as you start taking its address via "&x".

>Note that this is a C++ thing. An RC file needs a #define, not a const
>declaration.

Because it is a Microsoft invention ? ;)
I still think they do C instead of C++. Think of all the windows stuff,
it looks way too complicated to me. Even in DirectX they still want
structs to be initialised, hey don't they know constructors?

>>By the way what is wrong with
>>
>>int id = 1;
>>
>>const int x1 = id++;
>>const int x2 = id++;
>>const int x3 = id++;
>>etc
>
>
>You could always try it and read the errors it generates.

None?

>Assuming that this is file global, outside of classes, etc, there are
>problems with that. The declarations of x1, x2 and x3 are as a const, a
>value known at compile time.

Not necessarily.

>The problem with it is that the declaration of id is as a variable so
will
>be known for its value only at run time. The initialization value for
the
>const must be known at compile time.

Really? I don't think so. It compiles at least with BCB5. And I
think it should compile on any conforming compiler, too. Consider:

#include <iostream>
using namespace std;

struct foo{
int i;
foo(int i_) : i(i_) { cout << "Hello World!" << endl; }
};

const foo f(4);

int main() { &f; }

I think this should compile. I think it does occupy memory.
Now, how are ints different from foo?
 

Re:Re: #define auto increment

Hi!
Ed Mulroy [TeamB] wrote:
Quote
A const must be initialized with a literal or another const to be a const at
compile time. For example:
Correct. But not every const (even not every const int) must be a
compile time constant. THAT was my point.
Quote
int main()
{
char buf1[x1]; // line 18
char buf2[x2]; // line 19
char buf3[x3]; // line 20
Of course you need compile time constants here. But we were not talking
about using constants to specify array sizes, instead we are talking
about ids, which not necessarily have to be compile time constants.
Quote
And if you build with XCONST defined and with an added -S to the left of the
file name on the command line you will then be able to look a the generated
*.asm file and see for yourself that there is not even one byte assigned to
all of the constant integers x1, x2 and x3.
But if I put a single "&x1" into the code, then the compiler will
reserve space for it.
Frank