Const and macro

Hi,
can any one give proper reason why should i use const as compaire to macro ?

Quote:

---

Originally Posted by Brw_Abhi

Hi,
can any one give proper reason why should i use const as compaire to macro ?

---

An evil header file can redefine your macro without your knowledge. A header file trying to redefine your const will throw a compile error.

You can take the address of a const -- can't do that with a macro.

Why use a hack (macros) when there are finally better methods available?

Yes. Read Stroustrup's answer to the FAQ: So, what's wrong with using macros?

the only legitimate use of #macro preprocessor seems to be for skipping unneeded parts at compile time.
for example, use #ifdef etc, but, that's all
there are much better ways in C++ than to do this silly thing:
#define PI 3.14if0rg0t

No, macros have so much more use than that, but they are also evil at the same time, so avoiding them and using them wisely is a good idea.
(They can, for example, increase readability by picking away large chunks of code that can't be shortened by typedefs [for example, templates], among other things.)

Quote:

---

Originally Posted by Elysia

No, macros have so much more use than that, but they are also evil at the same time, so avoiding them and using them wisely is a good idea.
(They can, for example, increase readability by picking away large chunks of code that can't be shortened by typedefs [for example, templates], among other things.)

---

Tools are not innately evil, people can only use the in evil ways.

Also, macros can't be separated by namespaces, so macro name collisions are much more common than variables separated by namespaces.

>> Tools are not innately evil, people can only use the in evil ways.
Calling a tool "evil" that makes it unecessarily easy for users to use it in evil ways is acceptable.

Pointers and references are evil, too, then I guess. C++ is an evil language. Look at the majority of questions on the forum. People doing careless things easily.

Blame the carpenter, not the tool.

Do pointers and references make it unnecessarily easy for a user to use them evilly? Are there alternatives that are harder to do evil with?

Blame the tool when the tool deserves blame. If you buy a nail gun that shoots the nails in both directions, then that nail gun is evil. Yes, you should be careful and read the directions and only use that nail gun when you have to drive a nail into two different directions, but the tool still certainly deserves blame for all the people with nails in their eye.

Quote:

---

Originally Posted by Daved

Are there alternatives that are harder to do evil with?

---

[strawman argument elided]

Sure, there are alternatives - use Java or C# instead. The overwhelming majority of people that use C++ aren't disciplined or responsible enough to use it and would be better served with a simpler language. I'm tired of seeing the language criticized because of the actions of lazy and/or bad programmers.

It doesn't sound like you understood what I was trying to get at. Then again, you accuse me of using a strawman argument, so perhaps I'm not understanding you. I think you implied that a tool cannot be considered evil. I am claiming that a tool can be considered evil.

References are not considered evil because they do not unnecessarily allow users to do bad things with them, and there are no alternatives that are less evil.

Macros are considered evil because they do allow users to do evil (by polluting namespaces, ignoring type rules, etc) and there are generally better alternatives (const, inline, etc).

So, for someone to call a tool (in this case a feature of C++) evil is completely acceptable because there is an inherent difference between the evil tool and the not evil alternative.

Well I think Java is evil. ;)
But then again, there are a few parts of C++ I would have liked to have seen done differently, but some of them would have broken compatability with C... Why that's such a bad thing, I'm not sure; just name your C files .c and C++ files .cpp and they should use the right rules for compiling each (but then you'd need to use .hpp files instead of .h for C++).

Another reason is that you can't change the value of a macro at run time but you can change the value of a const at run time (if you do it right and set things up properly)

Hmmm. We might be stretching the rules a bit there if we want to modify the value of a const...
But it's certainly doable and acceptable in some cases.

No stretching of the rules required.

Modify const? No stretching? Const isn't supposed to be modified...

Have you an example, Thantos? Assignment to a const seems illegal by definition.

const doesn't have to be universal to all that can see it.

Off the top of my head

foo.h

Code:

---

#ifndef FOO_H_
#define FOO_H_

#ifndef FOO_C_
extern const int x;
#endif

void changevalue(int v);

#endif

---

foo.c

Code:

---

#define FOO_C_

#include "foo.h"

int x = 5;

void changevalue(int v)
{
        x = v;
}

---

bar.c

Code:

---

#include <iostream>
#include "foo.h"

int main()
{
        std::cout<<"Before: "<<x<<std::endl;
        changevalue(4);
        std::cout<<"After: "<<x<<std::endl;
}

---

Granted that isn't the same as having:

const int foo = 5;

Quote:

---

const doesn't have to be universal to all that can see it.

---

Oh, but then in the given context it implies that the variable is not const.

I'll accept that one, though! You can protect certain files from writing to a global variable, yet being able to read it.
But this wouldn't be possible with a macro.

Quote:

---

Originally Posted by laserlight

Oh, but then in the given context it implies that the variable is not const.

---

Yes and no. To everyone but the one file the variable is const. const just ensures that you can't change it. Lets say you had:

Code:

---

volatile const int x;

---

Where x was tied to some hardware input. x is still const but it isn't a constant value and the compiler shouldn't assume it is.

Quote:

---

Originally Posted by Daved

It doesn't sound like you understood what I was trying to get at. Then again, you accuse me of using a strawman argument, so perhaps I'm not understanding you. I think you implied that a tool cannot be considered evil. I am claiming that a tool can be considered evil.

References are not considered evil because they do not unnecessarily allow users to do bad things with them, and there are no alternatives that are less evil.

Macros are considered evil because they do allow users to do evil (by polluting namespaces, ignoring type rules, etc) and there are generally better alternatives (const, inline, etc).

So, for someone to call a tool (in this case a feature of C++) evil is completely acceptable because there is an inherent difference between the evil tool and the not evil alternative.

---

Macros are easier to abuse, but they still have valid uses. A chainsaw is easier to abuse than a carving knife, which is why I don't keep one at the dinner table on Thanksgiving. If someone cuts off their hand with a chainsaw carving up a bird, it isn't the chainsaw's fault.

I think the problem is that the word "evil" is not well defined in this context, so the debate is rather pointless. Someone should write an essay entitled "Evil Considered Harmful".

Macro's aren't evil; they have their uses. And I'm not just talking about include guards.

But in C++, const variables are preferable to Macros, because they are type safe, and because they do not pollute the global namespace.

When there are two ways to solve a problem, and using a macro is one of them, chances are the other option is better.

But macros can be useful when you have a lot of repetitive code that cannot condensed within the syntax of the language. For example, if you have a lot of similar template specializations, that are nevertheless different from the default template.

I'm basically using this definition of evil: http://www.parashift.com/c++-faq-lit....html#faq-6.15

>> Macros are easier to abuse, but they still have valid uses.
Did somebody claim otherwise?

A tool that is easily abused can be called a bad tool. Whether you use the term evil or not isn't all that relevant. The point is that one should be wary of such a tool because it is easily abused. That does not imply that there are no valid uses.

I agree with your opinion on the proper use of macros.

I disagree that there is anything wrong with macros; If I were to asked to redesign the language I would keep macros the way they are.

Quote:

---

Off the top of my head

---

Instinctively, I'd say this is undefined behaviour.

Less instinctively, gcc refuses to compile it if you pass the implementation file and at least one using file at the same time and use -combine. (-combine only works for C currently.)

Edit: Finally found it! 3.5/10 in N2588 (most recent C++0x draft) says:
"[...] the types specified by all declarations referring to a given object or function shall be identical [...]. A violation of this rule on type identity does not require a diagnostic."

C99:

Quote:

---

Originally Posted by 6.2.7 Compatible type and composite type

2 All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.

---

Quote:

---

Originally Posted by 6.7.3 Type qualifiers

9 For two qualified types to be compatible, both shall have the identically qualified version of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers does not affect the specified type.

---

Aww CornedBee beat me

Quote:

---

Originally Posted by laserlight

I think the problem is that the word "evil" is not well defined in this context, so the debate is rather pointless. Someone should write an essay entitled "Evil Considered Harmful".

---

That gets my vote.

You're still allowed to do this, of course:

Code:

---

// x.hpp
extern const int &x;

// x.cpp
int real_x;
const int &x = real_x;

---

Quote:

---

Originally Posted by CornedBee

Instinctively, I'd say this is undefined behaviour.

Less instinctively, gcc refuses to compile it if you pass the implementation file and at least one using file at the same time and use -combine. (-combine only works for C currently.)

---

Compiled just fine using g++. Compiled foo.o, bar.o and then linked them

Of course that doesn't mean it isn't undefined.

As I said, both files at the same time and -combine:

Code:

---

gcc -o const -combine const1.c const2.c

---

You can't use gcc to compile c++ programs. I see that I did .c instead of .cpp, sorry about that.


Both gcc and g++ gave me "unrecongized option `-combine`". Changing cout to printf and compiling both as C gave me a working program.

IMO it is pretty silly to have that be undefined behavior but oh well.

Quote:

---

You can't use gcc to compile c++ programs.

---

Yes, you can. And it was me who changed the names to .c, because -combine is not implemented for C++.

I don't know what GCC version you have. Mine is 4.1.2.

3.something. Haven't had a need to update it. When I compiled the files using gcc I got syntax errors because of std::.

#macros are beautiful

Code:

---

#define IF if(
#define THEN ) {
#define ENDIF }
#define MARRY_GO_ROUND while(1) {;}

---

so sweet

Code:

---

IF 5 == 5 THEN
    MARRY_GO_ROUND
ENDIF

---

Quote:

---

Originally Posted by (::)

#macros are beautiful

Code:

---

#define IF if(
#define THEN ) {
#define ENDIF }
#define MARRY_GO_ROUND while(1) {;}

---

so sweet

Code:

---

IF 5 == 5 THEN
    MARRY_GO_ROUND
ENDIF

---

---

Ah, so that's how VB does it! LOL!

Quote:

---

Originally Posted by cpjust

Ah, so that's how VB does it! LOL!

---

hush hush hushssssss ... do not let the secret out :D lol lol lololololololololol!!!