Prev: Using pointer-to-member of incomplete type in constructor call in VS2008
Next: filename string manipulation
From: Igor Tandetnik on 5 Feb 2010 17:15
Robby <Robby(a)discussions.microsoft.com> wrote:
> I don't know about you guys, but the way I see the usefulness of
> macros would be lets say we are doing a function, and all of the
> sudden we need to do a calculation of some sort. Not to clutter up
> the code in the function, I would use a macro...

Why not another function? It's not like you are being charged per function used.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

From: Tamas Demjen on 5 Feb 2010 18:39
Robby wrote:

> So, in C, we *can't* have global static variables. I guess it would make
> sence though. If a variable is global, why would it need to be static. Its
> global! Its contents will never be lost!!!

I think you're mixing the terminology. The static keyword is context
sensitive, and depending on where it appears, it has a completely
different meaning. Declaring a variable in the global scope has nothing
to do with it being static or not.

Variables have a lifetime (duration) and a visibility, and those
concepts are more or less independent.

The global scope means you're not inside a function, structure, or
union. In simple terms, you're not inside a curly brace. Variables
in the global scope have the same lifetime as the application.
They never go out of scope, so they never lose their values.
Variables inside a function normally lose their values when the
function exits, unless they're declared static.

Visibility can be different than lifetime. A variable can be visible
inside a scope, in an entire .c file, or inside the entire executable.
In case of a DLL/shared object/dylib, you can also control whether a
variable or function is exported (available to the client of the
library).

Let's see an example for global and local scope:

// main.c
#include <stdio.h>

int global_scope;
// lifetime: global (until the app exits)
// visibility: global (for the entire executable/module)

void f()
{
int local_scope;
// lifetime: local (till the function exits)
// visibility: local (for this function only)
}

If you use the static keyword in the global scope, it means the variable
or function is only accessible in the translation unit where it's
declared:

static int internal_global;
// lifetime: global (until the app exits)
// visibility: local (for this .c unit only)

It's in the global scope, so it has a global life span, but it's local
in terms of accessibility. You can't refer to it from the outside.
static means it can't be extern, and other .c translation units can't
see it. You can define another internal_global variable in another .c
file without conflict.

The static keyword has a completely different meaning when used inside
a function:

int f()
{
static int call_counter = 0;
// lifetime: global (until the app exits)
// visibility: local (for this function only)
++call_counter;
}

This means the variable keeps its value in between function calls, but
it still remains private to the f() function. You can't possibly access
call_counter outside of f(), but due to its static nature, the variable
stays alive, even when the function returns.

Functions can also be declared static. Functions have visibility only,
no lifetime, so static only controls whether a function is hidden inside
a .c file, or visible across the entire project.

In C++ the static keyword has a whole bunch of other meanings.
A static member means it belongs to the class, not to the instance.
As you see, the static keyword is always interpreted
differently, depending on the context in which it appears.

Tom
From: Robby on 5 Feb 2010 19:12
"Igor Tandetnik" wrote:

> Robby <Robby(a)discussions.microsoft.com> wrote:
> > I don't know about you guys, but the way I see the usefulness of
> > macros would be lets say we are doing a function, and all of the
> > sudden we need to do a calculation of some sort. Not to clutter up
> > the code in the function, I would use a macro...
>
> Why not another function? It's not like you are being charged per function used.

Hi Igor,

No, no, no, I have a bigger processor now, with lots and lots of memory and
I could do as many functions as I want and that's without being charged. :-)

But just to reminisse here, so then lets do everything with functions. Why
bother with macros at all. Why even keep macros in the C language standard.
You read the article yourself, were supposed to say yuuuk! when we hear the
word "macro".

Also, I *think* having an important calculation such as the system frequency
calculation, would be a calculation deemed important to be set up there for
it to be globally defined as a macro. I might need this calculation on the
fly without going through a bunch of functions to find the one function that
does this very specific calculation. Anyway its just my *personal* opinion.

The important thing is that a group of C commands carry out logic that works
no matter if its done by a function or a macro. Maybe macros are not as safe
as functions but they do great when its for one *very* particular
calculation...
I guess! :-)

And I agree with you in a sence... I am not too crazy about doing long
macros either, a function is much more practicle.

Oh and by the way Uli, I did remove the conflicting gloabal variable you
were talking about. I only kept the one in the module for module scope. You
were right!

Thank you all for your help. Very appreciated!

Regards
Rob
From: Bo Persson on 6 Feb 2010 06:35
Robby wrote:
> "Igor Tandetnik" wrote:
>
>> Robby <Robby(a)discussions.microsoft.com> wrote:
>>> I don't know about you guys, but the way I see the usefulness of
>>> macros would be lets say we are doing a function, and all of the
>>> sudden we need to do a calculation of some sort. Not to clutter up
>>> the code in the function, I would use a macro...
>>
>> Why not another function? It's not like you are being charged per
>> function used.
>
> Hi Igor,
>
> No, no, no, I have a bigger processor now, with lots and lots of
> memory and I could do as many functions as I want and that's
> without being charged. :-)

It isn't that macros are any faster or smaller than functions, either.
You are not saving anything!

The article is about C++, which added const and inline to do most of
what macros do, but whithout resorting to simple text substitutions.
Now that C has also gotten these improved features, why not use them?

>
> But just to reminisse here, so then lets do everything with
> functions. Why bother with macros at all. Why even keep macros in
> the C language standard. You read the article yourself, were
> supposed to say yuuuk! when we hear the word "macro".

Macros are useful for include guards, and an occational #ifdef ABC.
The main reason for keeping them is of course that there are lots of
existing code that uses them. But there is not much reason for writing
new code using the old features.

>
> Also, I *think* having an important calculation such as the system
> frequency calculation, would be a calculation deemed important to
> be set up there for it to be globally defined as a macro. I might
> need this calculation on the fly without going through a bunch of
> functions to find the one function that does this very specific
> calculation. Anyway its just my *personal* opinion.

So you can have a global constant:

const int x = ;
const float y = ;

These will not magically replace every use of x and y in your program.

>
> The important thing is that a group of C commands carry out logic
> that works no matter if its done by a function or a macro. Maybe
> macros are not as safe as functions but they do great when its for
> one *very* particular calculation...
> I guess! :-)

The article showed that by including a header (like windows.h) before
your header, the function names in YOUR header will be randomly
replaced by other names, like Sleep becoming SleepEx.

If you then don't include the same headers in your .cpp file, you will
get a link time error. How bad is that?!


Bo Persson


From: Robby on 6 Feb 2010 14:29
"Bo Persson" wrote:

> Robby wrote:
> > "Igor Tandetnik" wrote:
> >
> >> Robby <Robby(a)discussions.microsoft.com> wrote:
> >>> I don't know about you guys, but the way I see the usefulness of
> >>> macros would be lets say we are doing a function, and all of the
> >>> sudden we need to do a calculation of some sort. Not to clutter up
> >>> the code in the function, I would use a macro...
> >>
> >> Why not another function? It's not like you are being charged per
> >> function used.
> >
> > Hi Igor,
> >
> > No, no, no, I have a bigger processor now, with lots and lots of
> > memory and I could do as many functions as I want and that's
> > without being charged. :-)
>
> It isn't that macros are any faster or smaller than functions, either.
> You are not saving anything!
>
> The article is about C++, which added const and inline to do most of
> what macros do, but whithout resorting to simple text substitutions.
> Now that C has also gotten these improved features, why not use them?
>
> >
> > But just to reminisse here, so then lets do everything with
> > functions. Why bother with macros at all. Why even keep macros in
> > the C language standard. You read the article yourself, were
> > supposed to say yuuuk! when we hear the word "macro".
>
> Macros are useful for include guards, and an occational #ifdef ABC.
> The main reason for keeping them is of course that there are lots of
> existing code that uses them. But there is not much reason for writing
> new code using the old features.
>
> >
> > Also, I *think* having an important calculation such as the system
> > frequency calculation, would be a calculation deemed important to
> > be set up there for it to be globally defined as a macro. I might
> > need this calculation on the fly without going through a bunch of
> > functions to find the one function that does this very specific
> > calculation. Anyway its just my *personal* opinion.
>
> So you can have a global constant:
>
> const int x = ;
> const float y = ;
>
> These will not magically replace every use of x and y in your program.
>
> >
> > The important thing is that a group of C commands carry out logic
> > that works no matter if its done by a function or a macro. Maybe
> > macros are not as safe as functions but they do great when its for
> > one *very* particular calculation...
> > I guess! :-)
>
> The article showed that by including a header (like windows.h) before
> your header, the function names in YOUR header will be randomly
> replaced by other names, like Sleep becoming SleepEx.
>
> If you then don't include the same headers in your .cpp file, you will
> get a link time error. How bad is that?!

That is bad!

Very interesting!

Thanks for your insight BO!

Regards
Rob
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Using pointer-to-member of incomplete type in constructor call in VS2008
Next: filename string manipulation