#define preprocessor

[Guest]

how I can do the following in C#, (the define line below)

c/c++ : #define MAX_LEN 0x23

for (int i=0;i<MAX_LEN;++)
array = 0xFF;

 

[Hans Kesting]

how I can do the following in C#, (the define line below)

c/c++ : #define MAX_LEN 0x23

for (int i=0;i<MAX_LEN;++)
array = 0xFF;

not *exactly* the same, but you could use

private const int MAX_LEN = 0x23;
(or "public" instead of "private")

 

[Guest]

No , this is not what I need , your suggestion allocate memory (sizeof
(int)), In my project there are more than 200 constants (define) , this will
need 200*4 = 800 bytes.
What I need is while running the compiler all the MAX_LEN will changed to be
the number I defined (pre compiler).

how I can do the following in C#, (the define line below)

c/c++ : #define MAX_LEN 0x23

for (int i=0;i<MAX_LEN;++)
array = 0xFF;

not *exactly* the same, but you could use

private const int MAX_LEN = 0x23;
(or "public" instead of "private")

 

[Gabriel Lozano-Morán]

In C++ there is a preprocessor that will react to the lines starting with #.
In C# there is no seperate preprocessor, instead you should use the const
keyword to achieve 'almost' the same.

Gabriel Lozano-Morán

No , this is not what I need , your suggestion allocate memory (sizeof
(int)), In my project there are more than 200 constants (define) , this
will
need 200*4 = 800 bytes.
What I need is while running the compiler all the MAX_LEN will changed to
be
the number I defined (pre compiler).

how I can do the following in C#, (the define line below)

c/c++ : #define MAX_LEN 0x23

for (int i=0;i<MAX_LEN;++)
array = 0xFF;

not *exactly* the same, but you could use

private const int MAX_LEN = 0x23;
(or "public" instead of "private")

 

[cody]

You could comment out everything you don't actually need.
But there is another solution. Some of the obfuscator tools out there have
features to automatically delete unused code from an assembly.
Honestly, do you really worry about this small overhead?

No , this is not what I need , your suggestion allocate memory (sizeof
(int)), In my project there are more than 200 constants (define) , this will
need 200*4 = 800 bytes.
What I need is while running the compiler all the MAX_LEN will changed to be
the number I defined (pre compiler).

how I can do the following in C#, (the define line below)

c/c++ : #define MAX_LEN 0x23

for (int i=0;i<MAX_LEN;++)
array = 0xFF;

not *exactly* the same, but you could use

private const int MAX_LEN = 0x23;
(or "public" instead of "private")

 

[Mattias Sjögren]

No , this is not what I need , your suggestion allocate memory (sizeof

(int)),

No it doesn't.

What I need is while running the compiler all the MAX_LEN will changed to be
the number I defined (pre compiler).

That's what the C# compiler does with constants.



Mattias

 

[Guest]

Hello Yosi,
Even in C++/C there will be 800 bytes allocated. These constants still
exist in memory in C++/C. As someone else pointed out, 800 bytes isn't a lot
of overhead to worry about. Unless your program is extremely massive.
Regards,
Mark

No , this is not what I need , your suggestion allocate memory (sizeof
(int)), In my project there are more than 200 constants (define) , this will
need 200*4 = 800 bytes.
What I need is while running the compiler all the MAX_LEN will changed to be
the number I defined (pre compiler).

how I can do the following in C#, (the define line below)

c/c++ : #define MAX_LEN 0x23

for (int i=0;i<MAX_LEN;++)
array = 0xFF;

not *exactly* the same, but you could use

private const int MAX_LEN = 0x23;
(or "public" instead of "private")

 

[Jon Skeet [C# MVP]]

That's what the C# compiler does with constants.

It does - the constants *do* live on in the compiled IL. It's a tiny,
tiny amount of memory to worry about, but it is there.

 

[Jon Skeet [C# MVP]]

Even in C++/C there will be 800 bytes allocated.

Only if the constants are used. In both cases, there'll be the size of
an int in the compiled code wherever it's used. In C#, there'll also be
the static member itself - including the name of it.

These constants still exist in memory in C++/C.

Only where used, in C++/C.

As someone else pointed out, 800 bytes isn't a lot
of overhead to worry about. Unless your program is extremely massive.

I'd say unless your program is absolutely tiny

Personally I think C# does it the right way...

 

[James Curran]

Even in C++/C there will be 800 bytes allocated. These constants still
exist in memory in C++/C. As someone else pointed out, 800 bytes isn't a lot
of overhead to worry about. Unless your program is extremely massive.

Um... Nope. If you say
#define MAX_LEN 0x23
for (int i=0;i<MAX_LEN;++i)

no space is allocated for MAX_LEN, and as far as the compiler is concerned,
you typed it as:
for (int i=0;i < 23;++i)

Now, if you were using C++ and had written:
const int MAX_LEN = 0x23;
for (int i=0;i<MAX_LEN;++)

Then the compiler is not required to allocate space for it, and very few
compilers will.

Only if you'd written something like:
const int MAX_LEN = 0x23;
const int* pMaxLen = &MAX_LEN;

then is the compiler require to allocate space for MAX_LEN.

 

[James Curran]

Interestingly, the compiler does it both ways. Given the code:
class Class1
{
const int Max_len = 23;
[STAThread]
static void Main(string[] args)
{
for (int i = 0; i < Max_len; ++i)
Console.WriteLine("{0}", i);
}
}

The generated IL (as decompiled by Reflector) shows that Max_len *is*
present in the EXE, but the code is compiled as:

private static void Main(string[] args)
{
for (int num1 = 0; num1 < 0x17; num1++)
{
Console.WriteLine("{0}", num1);
}
}

That's what the C# compiler does with constants.

It does - the constants *do* live on in the compiled IL. It's a tiny,
tiny amount of memory to worry about, but it is there.

 

[Jon Skeet [C# MVP]]

Interestingly, the compiler does it both ways. Given the code:
class Class1
{
const int Max_len = 23;
[STAThread]
static void Main(string[] args)
{
for (int i = 0; i < Max_len; ++i)
Console.WriteLine("{0}", i);
}
}

The generated IL (as decompiled by Reflector) shows that Max_len *is*
present in the EXE, but the code is compiled as:

private static void Main(string[] args)
{
for (int num1 = 0; num1 < 0x17; num1++)
{
Console.WriteLine("{0}", num1);
}
}

Exactly. That's the difference between declaring it as const and
declaring it as static readonly.

 

[Mattias Sjögren]

It does

Yeah that's what I said. Or did you mean to quote the other part of my
reply?

the constants *do* live on in the compiled IL. It's a tiny,
tiny amount of memory to worry about, but it is there.

Yes of course the value must exist somewhere. But the CLR doesn't have
to allocate space for the constant field (which I believe was what the
OP claimed would happen) since you're not allowed to use it at
runtime.



Mattias

 

[Jon Skeet [C# MVP]]

Yeah that's what I said. Or did you mean to quote the other part of my
reply?

Not entirely sure, looking back at it.

Yes of course the value must exist somewhere.

Whereas it doesn't using just a #define in C/C++ - an unused #define in
C/C++ would take absolutely no memory at all.

But the CLR doesn't have
to allocate space for the constant field (which I believe was what the
OP claimed would happen) since you're not allowed to use it at
runtime.

Can you not get the value by reflection? Maybe I'm wrong and you can't,
but if you *can*, then the value must have some space allocated for it
somewhere, wherever that is. (It's not once per instance, of course,
but I don't think the OP was saying that.)

 

[Guest]

there is no tiny amount of memory , when I buil ahuge application includes
more than 1000 constant, I will stop being a tiny amount of memory .
And Cody : yes I'm really worry about this small overhead :-(

 

[Jon Skeet [C# MVP]]

there is no tiny amount of memory , when I buil ahuge application includes
more than 1000 constant, I will stop being a tiny amount of memory .

It'll be 4K. That's still a tiny amount of memory to almost everyone, I
believe.

And Cody : yes I'm really worry about this small overhead :-(

If you're really worried about that size of memory, I suspect that .NET
isn't the right environment for you. You do know that all strings in
..NET are Unicode, right? As soon as you've got 2000 characters in use
in your app, if you actually know all of those characters are ASCII,
you're "wasting" the same amount of memory.

Are you writing code in a *really, really* constrained memory
environment or something? Even on the Compact Framework 4K is a very
small amount of memory over the lifetime of the whole app.

 

[Mattias Sjögren]

Can you not get the value by reflection? Maybe I'm wrong and you can't,
but if you *can*, then the value must have some space allocated for it
somewhere, wherever that is. (It's not once per instance, of course,
but I don't think the OP was saying that.)

Yes, but reflection gets it from metadata, not from the loaded type.
You can't use an IL instruction like ldsfld on it. So ideally the
value only takes up space in the (memory mapped) executable file.



Mattias

 

[Jon Skeet [C# MVP]]

Yes, but reflection gets it from metadata, not from the loaded type.

Ah, right.

You can't use an IL instruction like ldsfld on it. So ideally the
value only takes up space in the (memory mapped) executable file.

Fair enough. It's still "more present" than it is in a C/C++
executable, but frankly I think the idea that 4K is going to matter in
a huge app is misguided in the first place

 

[cody]

It'll be 4K. That's still a tiny amount of memory to almost everyone, I
believe.

But what about that constant identifiers? I assume they will be stored as
strings in the executable too.

 

[Jon Skeet [C# MVP]]

But what about that constant identifiers? I assume they will be stored as
strings in the executable too.

Yes, in the executable - but they won't need to be loaded into the
heap; they can stay memory mapped in the file.